Le 10 août 2026 à 21 h 05 UTC, une modification minuscule a été fusionnée dans un dépôt GitHub nommé bitcoin/bips. La demande de fusion n° 2245, ouverte la veille par Jon Atack, l’un des cinq éditeurs de BIP, changeait un seul mot dans l’en-tête du BIP 110 : son statut devenait « Closed » (clos). Deux jours plus tôt, un soft fork décrit par ce document avait détaché une poignée de nœuds sur une chaîne qui s’était presque aussitôt arrêtée. La demande de fusion n’empêchait personne de continuer à appliquer ces règles. Elle consignait seulement, dans l’archive de chaque Bitcoin Improvement Proposal (proposition d’amélioration de Bitcoin, ou BIP), que la tentative était terminée.
Ce simple mot a pourtant suscité 32 commentaires. Éditeurs et relecteurs se sont demandé si un soft fork raté devait passer par le statut « Deployed » (déployé), puisque des logiciels appliquant ses règles avaient été distribués, avant d’être clos. Greg Maxwell, développeur de Bitcoin de longue date, a récusé le débat entier : « Le dépôt des BIP n’est absolument pas la gouvernance de Bitcoin », a-t-il écrit dans la discussion (traduction). Deux jours après la fusion, Greg Tonoski, partisan du BIP-110, a objecté que les règles s’étaient activées à la hauteur inscrite dans la spécification et que les nœuds qui les appliquaient encore étaient libres de le faire.
Bitcoin n’a ni conseil d’administration, ni directeur général, ni vote, et ses règles ont pourtant changé, le plus visiblement avec SegWit en 2017 et Taproot en 2021. Chaque changement a traversé les mêmes couches : un document public, du code que quelques mainteneurs fusionnent, une méthode pour enclencher les nouvelles règles, et des milliers d’opérateurs qui décident ce qu’ils font tourner. Quand les couches ne s’accordent pas, cela donne une bataille.
Si vous cherchiez « bitcoin BIP » en pensant aux 12 ou 24 mots de votre portefeuille, vous avez croisé le BIP 39, un standard parmi plus de 200 propositions. Ce cours remonte à la source : comment ces documents naissent, qui les écrit, qui les publie, et qui décide en pratique de ce que Bitcoin devient.
Cette leçon fait suite à notre leçon sur les couches 2 et les sidechains de Bitcoin, qui montrait tout ce qui peut se construire sans toucher aux règles de base. Un rappel avant d’aller plus loin : un soft fork ne fait que durcir les règles, si bien que les nœuds non mis à jour continuent de suivre la chaîne tant que la majorité de la puissance de calcul applique les nouvelles règles, alors qu’un hard fork assouplit ou modifie les règles et laisse derrière lui les nœuds non mis à jour. Notre guide des soft forks, hard forks et scissions de chaîne explique les deux, montre comment les mineurs signalent leur accord et raconte la scission du BIP-110 du 8 août 2026 bloc par bloc. La présente leçon traite de la question : qui a décidé, et comment.
Qui dirige Bitcoin ? Quatre pouvoirs et aucun propriétaire
Pour lire la gouvernance de Bitcoin, blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">il est utile de séparer quatre pouvoirs que l’on confond souvent. Les développeurs proposent des changements et écrivent le code. Les nœuds complets, que chacun peut faire tourner, vérifient chaque bloc d’après les règles du logiciel que leurs propriétaires ont choisi d’installer. Les mineurs rangent les transactions dans des blocs et, pendant un soft fork, signalent s’ils sont prêts à appliquer de nouvelles règles. Les utilisateurs économiques (plateformes d’échange, dépositaires, commerçants, détenteurs) décident quelle chaîne ils appellent bitcoin et acceptent en paiement. Dans les faits, aucun groupe n’a réussi à imposer un changement aux trois autres, et les évolutions sont lentes.
Notre leçon sur ce que fait un nœud et pourquoi il compte couvre le versant de l’application des règles. En bref : une règle n’existe que si le logiciel que les gens font réellement tourner l’applique. Un code que personne n’installe ne change rien, et un bloc que les nœuds rejettent ne vaut rien pour le mineur qui l’a produit.
Les acteurs du projet décrivent cet équilibre avec des mots différents. Le README du dépôt des BIP écrit que « l’acceptation et l’adoption reviennent en dernier ressort aux utilisateurs de Bitcoin » (traduction) et renvoie vers une page sur la « majorité économique ». Une déclaration signée en juin 2025 par 31 contributeurs de Bitcoin Core affirme que le réseau est défini par ses utilisateurs et que « les contributeurs de Bitcoin Core ne sont pas en position d’imposer » ces politiques (traduction), c’est-à-dire celles que les utilisateurs appliquent. Les partisans du BIP-110 donnent plus de poids aux opérateurs de nœuds : Tonoski a estimé, dans la demande de fusion du BIP 110, à 18 000 les nœuds de validation complète qui n’avaient pas rejeté le soft fork, un chiffre qu’il n’a pas sourcé. D’autres pointent la puissance de calcul, qui a décidé en pratique, en août 2026, quelle chaîne continuait de grandir. Aucune de ces lectures n’est une doctrine officielle, faute de bureau pour en publier une.
À comparer avec la gouvernance par jetons dans la finance décentralisée, où les détenteurs d’un jeton de gouvernance votent et où un contrat intelligent exécute le résultat. Bitcoin n’a ni jeton de ce type ni vote on-chain. Ses « votes » sont des choix de logiciel, faits machine par machine.
Qu’est-ce qu’un BIP Bitcoin, et comment vit-il et meurt-il ?
Un Bitcoin Improvement Proposal, ou BIP, est un document de conception. Il décrit une modification du protocole, du fonctionnement des logiciels autour de Bitcoin ou du processus lui-même, dans un format fixe : un en-tête, une motivation, une spécification et une section sur la rétrocompatibilité. Certains numéros sont connus de personnes qui n’en ont jamais lu un : le BIP 39 est le standard qui transforme le secret d’un portefeuille en 12 ou 24 mots de phrase de récupération, et le BIP 141 est le principal document de SegWit. Le BIP 39, de loin le plus connu des utilisateurs de portefeuilles, n’est qu’une proposition parmi plus de 200 dans la liste du dépôt.
Un dépôt public où publier ne veut pas dire approuver
Les BIP vivent dans le dépôt bitcoin/bips sur GitHub. Son README fixe l’ordre des choses : l’auteur décrit d’abord son idée sur la liste de diffusion bitcoindev, recueille des retours, et n’ouvre une demande de fusion que lorsque le brouillon a bien avancé. Les auteurs ne choisissent pas leur numéro. Un éditeur de BIP en attribue un lorsque la proposition remplit les critères éditoriaux, et la publie en fusionnant la demande.
Le README est explicite sur ce que signifie la publication. Qu’un BIP figure dans le dépôt « n’indique pas que c’est une bonne idée, qu’il a l’adhésion de la communauté ou qu’il est sur le point d’être adopté », dit-il (traduction), et les éditeurs sont censés publier de façon libérale et s’abstenir de décider au nom de la communauté. Lorsque les éditeurs ne s’accordent pas sur la publication d’une proposition controversée, l’option prudente s’applique et la proposition est close. Les cinq éditeurs listés dans le BIP 3 au 9 novembre 2026 sont Bryan Bishop, Jon Atack, Mark « Murch » Erhardt, Olaoluwa Osuntokun et Ruben Somsen.
Draft, Complete, Deployed, Closed : le cycle de vie du BIP 3
Le processus est lui-même décrit par un BIP. Pendant presque neuf ans, ce fut le BIP 2, rédigé par Luke Dashjr et numéroté en février 2016, avec des statuts comme Proposed, Final, Rejected, Withdrawn et Replaced. Son successeur, le BIP 3, « Updated BIP Process », écrit par Murch et numéroté le 9 janvier 2025, a désormais le statut Deployed, tandis que le BIP 2 est marqué Closed. Les anciens libellés figurent encore dans de vieux articles et se lisent comme de l’histoire.
Quatre statuts subsistent dans le BIP 3. Un Draft est une proposition en cours de travail ; s’il s’enlise pendant un an ou laisse des retours sans réponse, n’importe qui peut proposer de le clore, et il l’est sauf si les auteurs indiquent sous quatre semaines qu’ils continuent. Complete signifie que les auteurs jugent la spécification solide et recommandent l’adoption ; un BIP de spécification doit pour cela disposer d’une implémentation de référence fonctionnelle et de vecteurs de test, et Complete est le statut final de la plupart des BIP informatifs aboutis. Deployed est réservé à un BIP stabilisé et dont l’usage actif est démontré, et « une fois Deployed, le BIP est considéré comme définitif » (traduction). Closed couvre ce qui n’a plus qu’un intérêt historique. Rien n’est supprimé : un BIP clos reste dans l’archive, avec une ligne de journal des modifications qui explique pourquoi.
La règle du statut Deployed est ce dont discutait la demande de fusion du BIP 110. Le BIP 3 accepte comme preuve d’usage actif « un projet établi ayant déployé la prise en charge du BIP dans des versions de logiciel pour le réseau principal » (traduction), et Knots, un logiciel de nœud, avait distribué les règles ; il accepte aussi que les critères d’activation d’un soft fork soient remplis sur le réseau, ce qui n’était pas arrivé sur la chaîne principale. Murch, qui avait d’abord accepté de passer par Deployed, a changé de position le 10 août et écrit que traiter une tentative d’activation ratée comme un déploiement « semble un peu étrange » (traduction). La demande a été réécrite pour passer directement à Closed et fusionnée le soir même. Le journal du BIP indique désormais, à la version 1.0.1 datée du 9 août 2026, « Mark as Closed, following a chain split with stalled mining » (marqué comme clos, à la suite d’une scission de chaîne avec un minage à l’arrêt).
Tous les BIP ne touchent pas aux règles
Seule une minorité de BIP modifie le consensus, comme le BIP 141 pour SegWit ou les BIP 340 et 341 pour les signatures de Schnorr et Taproot, tous Deployed. D’autres sont des standards que les portefeuilles suivent sans aucun fork, comme les BIP 39 et BIP 32 pour les portefeuilles déterministes hiérarchiques. Le BIP 3 range les documents en trois types : Specification, Informational (où sont classées les méthodes d’activation BIP 9 et BIP 8) et Process, comme le BIP 3 lui-même. Le tableau du dépôt attribue à chaque proposition une couche, un type et un statut, et reste le moyen le plus rapide de voir où elle en est.
Qui écrit le code : Bitcoin Core, ses mainteneurs et les autres clients
La plupart des nœuds joignables font tourner Bitcoin Core, le logiciel issu du client d’origine de Satoshi Nakamoto. Changer Bitcoin revient en pratique le plus souvent à changer Bitcoin Core, si bien que ses règles d’acceptation du code comptent presque autant que le processus des BIP.
Comment un changement entre dans Bitcoin Core
Le fichier CONTRIBUTING du projet commence par dire qu’il n’existe « pas de notion particulière de « développeurs de Bitcoin Core » au sens de personnes privilégiées » (traduction). N’importe qui peut ouvrir une demande de fusion ; n’importe qui peut en relire une. Les relecteurs emploient un court vocabulaire : un Concept ACK soutient l’idée, un Approach ACK soutient l’idée et la façon de la réaliser, un NACK s’y oppose. Un NACK doit être motivé, et le fichier précise que les NACK sans justification peuvent être écartés.
Fusionner est autre chose. Le même fichier indique que la fusion d’une demande « relève des mainteneurs de fusion du projet » (traduction), qui jugent si elle respecte les principes du projet, satisfait ses normes et reflète « le consensus général des contributeurs » (traduction). Pour les changements de consensus, la barre est plus haute : ces correctifs doivent être précédés d’une longue discussion sur la liste de diffusion, accompagnés d’un BIP numéroté et soutenus par un consensus technique largement perçu. Le BIP est un préalable, pas un billet d’entrée : une proposition numérotée peut rester des années sans être fusionnée.
Une poignée de mainteneurs de fusion, et aucune mise à jour automatique
Le projet compte un petit groupe de mainteneurs qui détiennent des clés capables de fusionner dans le dépôt principal. Protos rapportait en janvier 2026 que six personnes détenaient de telles clés de confiance, mais les comptes rendus publics sur l’identité de ces personnes ont changé plusieurs fois en 2026, et la liste se vérifie mieux sur les pages du projet que dans la presse. Ce qui ne change pas, c’est la limite de leur pouvoir : fusionner du code dans Bitcoin Core ne l’installe nulle part.
La déclaration de juin 2025 des contributeurs le dit sans détour : le projet évite les mises à jour automatiques, de sorte qu’« aucune entité ne peut imposer unilatéralement des changements aux utilisateurs de Bitcoin Core » (traduction). Chaque opérateur décide du moment de la mise à jour, de son principe, ou du passage à un autre logiciel. C’est pourquoi de vieilles versions restent en service des années.
Bitcoin Core et Knots, btcd et libbitcoin
Il existe d’autres nœuds complets que Bitcoin Core. Bitcoin Knots, dont le mainteneur principal est Luke Dashjr, repose sur le code de Bitcoin Core avec des options supplémentaires, dont beaucoup portent sur les transactions qu’un nœud relaie, comme -datacarriercost. En mai 2026, Knots a publié deux versions côte à côte : la 29.3.knots20260507, dont les notes disent qu’elle « ne prend pas en charge la prochaine mise à niveau réseau BIP110 (RDTS) » (traduction), et la 29.3.knots20260508, qui incluait le BIP-110 (appelé RDTS par Knots) et demandait aux utilisateurs de serveurs d’ajouter consensusrules=rdts à leur configuration. Les versions suivantes ont conservé ces règles. Les notes de la 29.5.knots20260508, dernière version listée sur le site de Knots au 9 novembre 2026, décrivent aussi un « soft fork de longue maturité des coinbase » qui retarde le moment où des pièces tout juste minées peuvent être dépensées ; Bitcoin Core n’a pas de telle règle.
btcd est une implémentation indépendante de nœud complet écrite en Go, et libbitcoin est un ensemble séparé de bibliothèques C++ avec son propre nœud. Les deux sont bien moins répandus sur le réseau.
Le nombre de nœuds qui font tourner chaque logiciel ne peut qu’être estimé, car un nœud annonce lui-même une chaîne « user agent » qu’il peut modifier, et les nœuds qui n’acceptent aucune connexion entrante ou qui passent par Tor sont souvent manqués. Le tableau ci-dessous compte les chaînes user agent dans un instantané du robot d’exploration Bitnodes (btcnodes.io) ; ce n’est pas un recensement.
| Logiciel (chaîne user agent) | Nœuds | Part |
|---|---|---|
| Chaînes contenant « Knots » | 2 066 | 9,9 % |
| Autres chaînes « /Satoshi: » (Bitcoin Core) | 18 701 | 89,8 % |
| Autres clients (btcd et autres) | 65 | 0,3 % |
| Total des nœuds joignables | 20 832 | 100 % |
| Chaîne la plus fréquente : /Satoshi:32.1.0/ | 4 323 | 20,8 % |
| Chaîne Knots la plus fréquente : /Satoshi:29.3.0/Knots:20260507/ | 1 387 | 6,7 % |
Source : instantané de l’API Bitnodes du 9 novembre 2026 à 08 h 56 UTC, décompte de Coindaro. Les user agents sont déclarés par les nœuds eux-mêmes.
Ces chaînes disent aussi quelque chose de l’épisode BIP-110. Dans le même instantané, 1 413 chaînes Knots portaient l’étiquette 20260507, la version qui laissait le BIP-110 de côté, contre 4 portant l’étiquette 20260508 des versions qui l’incluaient. Une chaîne est auto-déclarée et ne prouve pas quelles règles un nœud applique, mais elle suggère que la plupart des nœuds Knots joignables sont restés sur la version sans le soft fork.
D’autres relevés donnent d’autres chiffres. Un instantané du 18 octobre 2026 de l’Institut de technologie de Karlsruhe, utilisé dans notre article sur les nœuds Bitcoin Core périmés, comptait 1 096 chaînes Knots parmi 9 691 pairs, soit environ 11 %. Les observatoires emploient des méthodes différentes et atteignent des nœuds différents : l’écart entre deux d’entre eux n’est pas une tendance.
Qui paie les développeurs
Aucune entreprise Bitcoin ne rémunère les développeurs de Bitcoin. Les contributeurs sont financés par un assemblage d’associations, d’entreprises et de bourses. OpenSats, organisme caritatif américain de type 501(c)(3) doté d’un conseil de neuf membres, indique sur son site avoir alloué 21 646 000 $ à des projets libres et open source et envoyé environ 24,6 milliards de sats à 252 bénéficiaires dans 40 pays, des chiffres affichés sans date et lus le 9 novembre 2026 ; Bitcoin Core figure parmi les projets qu’il liste. Brink, fondé en 2020 avec le soutien financier de John Pfeffer et Wences Casares, dit être financé à 100 % par des dons, et gère un programme de bourses pour de nouveaux contributeurs ainsi que des subventions pour des ingénieurs de protocole confirmés.
D’autres contributeurs travaillent pour des entreprises. Chaincode Labs résume sa raison d’être en une ligne : il « existe pour soutenir Bitcoin » (traduction). Spiral, qui s’appelait Square Crypto jusqu’à son changement de nom le 1er décembre 2021, se présente comme une initiative de Block d’intérêt public et écrivait lors de ce changement qu’elle doit être indépendante de son bienfaiteur. Les entreprises donnent aussi par l’intermédiaire de ces organisations : le 16 octobre 2026, OpenSats a annoncé le premier don dans le cadre du soutien récurrent de Strive à son Red Team Fund. Il n’existe pas de décompte public et faisant autorité des développeurs financés de Bitcoin Core.
Où l’on débat des propositions : liste de diffusion, forum et GitHub
L’essentiel des débats se tient à trois endroits. La liste de diffusion bitcoindev est la plus ancienne. Après des hébergements antérieurs, dont SourceForge et la Linux Foundation, elle est passée chez Google Groups, une migration annoncée par le modérateur Bryan Bishop dans un courriel daté du 9 février 2024 ; ses archives sont reproduites hors de Google, sur gnusha.org et mirror.b10c.me, et se lisent donc sans compte. Le forum Discourse delvingbitcoin.org a pour slogan « A place to dig deep into Bitcoin » (un lieu pour creuser Bitcoin en profondeur), avec des catégories pour la conception du protocole, l’implémentation et l’économie, et beaucoup de discussions de conception y commencent désormais. GitHub héberge la relecture du code elle-même, dans le dépôt bitcoin/bitcoin pour Core et bitcoin/bips pour les documents.
Suivre une proposition en pratique demande quelques étapes, dont aucune ne requiert d’autorisation :
- Retrouvez le numéro du BIP et son statut dans le tableau du README de bitcoin/bips, puis lisez l’en-tête du document et son journal des modifications.
- Cherchez son nom dans les archives de bitcoindev et sur delvingbitcoin.org pour lire les arguments pour et contre, avec les réponses des auteurs.
- Repérez une demande de fusion d’implémentation dans Bitcoin Core ou un autre client, et notez si elle inclut des paramètres d’activation pour le réseau principal ou seulement pour les réseaux de test.
- Lisez la lettre hebdomadaire Bitcoin Optech (en anglais) et ses pages thématiques, comme celle sur l’activation des soft forks, qui résument les discussions avec des liens.
- Vérifiez quelle version de votre propre logiciel de nœud vous utilisez, puisque c’est elle qui décide des règles que votre nœud applique.
Comment un soft fork est enclenché : les méthodes d’activation comparées
S’accorder sur un changement ne règle que la moitié du problème. L’autre moitié consiste à l’enclencher sans scinder la chaîne. Les soft forks de Bitcoin ont le plus souvent été activés en comptant les signaux des mineurs dans le champ de version des blocs, le mécanisme que détaille notre guide des forks. Ce qui a changé après chaque bataille, c’est qui pouvait bloquer le décompte : les mineurs ou les opérateurs de nœuds.
Rédigé par Pieter Wuille et numéroté en octobre 2015, le BIP 9 pose la base : 29 bits de version utilisables, une fenêtre avec un début et une échéance, et un échec si l’échéance arrive la première. En 2017, il a montré qu’une minorité de puissance de calcul pouvait retenir un changement en ne le signalant pas. Le BIP 8, de Shaolin Fry et Luke Dashjr, compte en hauteurs de blocs et ajoute une option, lockinontimeout ou LOT : avec LOT à true, les mineurs doivent signaler pendant la dernière période, de sorte que le changement est verrouillé à l’échéance quoi qu’ils veuillent. Le BIP 8 a le statut Complete ; un déploiement de Taproot avec LOT=true, le BIP 343, est aujourd’hui Closed, son journal citant « l’absence de déploiements connus » (traduction).
| Méthode | Seuil | Horloge | Les mineurs peuvent-ils la bloquer ? | Utilisée pour |
|---|---|---|---|---|
| BIP 9, bits de version | 95 % (1 916 blocs sur 2 016) | Horodatages, avec échéance | Oui : elle échoue à l’échéance | Déploiement de SegWit, 2016-2017 |
| BIP 148, soft fork activé par les utilisateurs | Aucun : les nœuds rejettent les blocs sans signal à partir du 1er août 2017 | Date fixe | Non, si assez de nœuds et d’acheteurs suivent | Forcer le signalement de SegWit, 2017 |
| BIP 91, activation à seuil réduit | 80 % (269 blocs sur 336) | Horodatages | Oui, en dessous de 80 % | Verrouiller SegWit, juillet 2017 |
| BIP 8 avec LOT=true | Configurable | Hauteurs de blocs | Non : signalement obligatoire à la fin | Jamais déployé sur le réseau principal |
| Speedy Trial (variante du BIP 9) | 90 % (1 815 sur 2 016) | Du 24 avril au 11 août 2021, hauteur minimale d’activation | Oui, dans une fenêtre courte | Taproot, 2021 |
| BIP-110 (BIP 9 modifié) | 55 % (1 109 sur 2 016), puis signalement obligatoire | Hauteurs de blocs à partir de 961 632 | Seulement par la scission de la chaîne | BIP-110, août 2026 : échec |
Sources : BIP 8, 9, 91, 110, 148, 341 et 343 du dépôt bitcoin/bips, lus le 9 novembre 2026.
Deux constantes ressortent. Les méthodes qui laissent les mineurs bloquer un changement (BIP 9, Speedy Trial) n’ont jamais scindé la chaîne quand elles échouaient : le changement n’a simplement pas eu lieu. Les méthodes qui le forcent (BIP 148, BIP 8 avec LOT=true, signalement obligatoire du BIP-110) ne fonctionnent que si la majeure partie de l’économie et de la puissance de calcul suit, et scindent la chaîne dans le cas contraire. La manière dont SegWit et Taproot ont ensuite transformé les transactions est détaillée dans notre leçon sur SegWit et Taproot ; ici, seul le chemin vers l’activation compte.
Trois batailles sur les règles de Bitcoin, datées
| Date | Événement |
|---|---|
| 22 juin 2015 | Numéro attribué au BIP 101 (blocs de 8 Mo, seuil de 75 % des mineurs) ; distribué dans Bitcoin XT en août |
| 12-13 sept. 2015 | Atelier Scaling Bitcoin, Montréal |
| 6-7 déc. 2015 | Scaling Bitcoin, Hong Kong : Pieter Wuille présente Segregated Witness |
| 23 mai 2017 | Publication de l’accord de New York : SegWit à 80 % sur le bit 4, un hard fork à 2 Mo sous six mois |
| 21-23 juil. 2017 | Le BIP 91 est verrouillé (bloc 476 784) puis activé (bloc 477 120) |
| 1er août 2017 | Date de départ du BIP 148 ; Bitcoin Cash se détache |
| 9 août 2017 | SegWit verrouillé (période commençant au bloc 479 808) |
| 24 août 2017 | SegWit actif, bloc 481 824, 01 h 57 UTC |
| 8 nov. 2017 | Hard fork SegWit2x suspendu |
| 13 juin 2021 | Taproot verrouillé (période se terminant au bloc 687 455, 20 h 06 UTC) |
| 14 nov. 2021 | Taproot actif, bloc 709 632, 05 h 15 UTC |
| 27 avr. 2025 | Ouverture de la demande de fusion n° 32359 pour retirer les limites d’OP_RETURN de Bitcoin Core (close sans fusion le 12 mai) |
| 6 juin 2025 | Déclaration de 31 contributeurs de Bitcoin Core sur la politique de relais |
| 9 juin 2025 | Fusion de la demande n° 32406 « policy: uncap datacarrier by default » |
| 10 oct. 2025 | Publication de Bitcoin Core 30.0 avec la nouvelle valeur par défaut |
| 3 déc. 2025 | Numéro 110 attribué au BIP |
| 8 août 2026 | Signalement obligatoire du BIP-110 au bloc 961 632 ; la chaîne minoritaire s’arrête |
| 10 août 2026 | BIP 110 marqué Closed (fusion de la demande n° 2245) |
Sources : textes des BIP, scalingbitcoin.org, presse de mai et novembre 2017, notes de version de Bitcoin Core et GitHub, heures des blocs de mempool.space, lus le 9 novembre 2026.
2015-2017 : la guerre de la taille des blocs et SegWit
La première bataille portait sur la capacité. Les blocs de Bitcoin étaient plafonnés à 1 Mo, et un camp voulait relever ce plafond par un hard fork. Le BIP 101, de Gavin Andresen, numéroté le 22 juin 2015, proposait des blocs de 8 Mo dès janvier 2016, doublant tous les deux ans, activés quand 750 blocs sur 1 000 signalaient. Son texte justifie le seuil de 75 % par la volonté d’éviter qu’un grand pool de minage dispose d’un veto effectif. Bitcoin XT, un client alternatif, l’a distribué en août 2015. Il n’a jamais approché de l’activation, et le BIP 101 est aujourd’hui Closed.
Deux ateliers Scaling Bitcoin ont suivi, à Montréal en septembre 2015 et à Hong Kong en décembre, où Pieter Wuille a présenté Segregated Witness, un soft fork qui sortait les données de signature de la partie du bloc comptée par l’ancienne limite. SegWit a été déployé avec le BIP 9 dans Bitcoin Core en 2016, mais le signalement des mineurs est resté très en dessous de 95 % pendant des mois, tandis que de nombreux gros mineurs soutenaient des blocs plus grands.
Deux pressions ont brisé l’impasse en 2017. Des opérateurs de nœuds et certaines entreprises se sont rassemblés autour du BIP 148, le soft fork activé par les utilisateurs décrit dans notre guide des forks. Le 23 mai 2017, après une réunion tenue autour de la conférence Consensus à New York, un groupe d’entreprises et de mineurs a publié l’accord de New York, qui associait l’activation de SegWit à 80 % sur le bit 4 à un hard fork à 2 Mo sous six mois. Le BIP 91, de James Hilliard, mettait en œuvre la première moitié avec un seuil de 80 % sur 336 blocs et était actif depuis le 23 juillet. Le résumé de la période par Bitcoin Optech note que l’on discute toujours du poids respectif de chaque pression.
SegWit a été verrouillé le 9 août puis est devenu actif le 24 août 2017 ; le camp des gros blocs avait déjà lancé Bitcoin Cash le 1er août. La seconde moitié de l’accord, le hard fork à 2 Mo connu sous le nom de SegWit2x, a été suspendue le 8 novembre 2017 par un courriel de Mike Belshe, directeur général de BitGo, cosigné par cinq autres soutiens, qui écrivaient ne pas avoir « construit un consensus suffisant pour une mise à niveau propre de la taille des blocs pour le moment » (traduction). Les entreprises et les mineurs signataires de mai n’avaient aucun moyen de faire appliquer la seconde moitié par les nœuds.
2021 : Taproot et le compromis « Speedy Trial »
Taproot, la mise à niveau qui a apporté les signatures de Schnorr et un nouveau type de sortie, suscitait peu d’opposition technique. La bataille portait sur la méthode. Un camp voulait le BIP 8 avec LOT=true pour que les mineurs ne puissent pas le retarder ; un autre voulait LOT=false pour qu’une activation ratée ne puisse pas scinder la chaîne. Le BIP 343 consigne que le compromis, surnommé Speedy Trial, a été proposé par Russell O’Connor et esquissé sur la liste de diffusion par David Harding : une fenêtre courte, un seuil de 90 % et une hauteur minimale d’activation, afin que l’économie ait des mois pour se mettre à niveau après le verrouillage.
La version 0.21.1 de Bitcoin Core l’a distribué, les mineurs ont franchi le seuil à la mi-juin 2021 et Taproot est devenu actif en novembre sans scission. Taproot a ensuite rendu moins chères à écrire les inscriptions des Ordinals, Runes et BRC-20, ce qui a préparé la troisième bataille.
2025-2026 : OP_RETURN, Bitcoin Core v30 et BIP-110
La troisième bataille a commencé autour d’un paramètre de nœud, non d’une règle de consensus. Bitcoin Core relayait jusqu’ici les transactions portant au plus 83 octets dans une sortie OP_RETURN, une limite de politique et non une règle de validité : les mineurs pouvaient inclure des transactions plus grosses, et certains l’ont fait. Le 27 avril 2025, Peter Todd a ouvert la demande de fusion n° 32359 pour supprimer ces limites ; elle a été close sans fusion le 12 mai. Une seconde, n° 32406, « policy: uncap datacarrier by default », ouverte le 2 mai et fusionnée le 9 juin 2025, est celle que créditent les notes de version de Bitcoin Core 30.0.
Publiée le 10 octobre 2025, la version 30.0 de Bitcoin Core a porté la valeur par défaut de -datacarriersize à 100 000 octets, ce qui supprime en pratique le plafond puisque la taille maximale de transaction est atteinte avant, et a autorisé plusieurs sorties OP_RETURN par transaction. Les opérateurs peuvent toujours fixer -datacarriersize=83 pour rétablir l’ancienne limite. Avant la publication, 31 contributeurs avaient exposé leur raisonnement dans une déclaration datée du 6 juin 2025 : la politique de relais devrait prédire ce que les mineurs vont miner plutôt que tenter de bloquer des transactions soutenues par une demande durable. Ils ajoutaient : « Cela ne revient pas à approuver ou cautionner l’usage non financier des données » (traduction).
Les critiques, dont beaucoup d’utilisateurs de Knots, ont jugé que le changement invitait davantage de données non financières dans les blocs, et certains opérateurs ont changé de logiciel de nœud. Certains ont alors porté le différend de la politique vers le consensus. Le BIP 110, « Reduced Data Temporary Softfork », signé du pseudonyme Dathon Ohm, a reçu son numéro le 3 décembre 2025. Il proposait de transformer des limites sur les données en règles de consensus pendant environ un an, avec un seuil de 55 % et un signalement obligatoire à partir du bloc 961 632. Knots l’a distribué dans une version séparée ; Bitcoin Core ne l’a pas fait.
Les mineurs n’ont pas suivi. Le 8 août 2026, les nœuds appliquant ces règles se sont séparés sur une chaîne qui s’est arrêtée, comme le raconte le guide des forks bloc par bloc. Le 12 août, Murch comptait quatre blocs sur la pointe minoritaire contre 533 sur la chaîne principale, et écrivait dans la demande de fusion du BIP 110 que le déploiement « a été rejeté de façon décisive par le réseau Bitcoin » (traduction). Tonoski et d’autres partisans ont maintenu que le soft fork s’était activé comme spécifié.
Soft forks Bitcoin à l’étude en novembre 2026
Plusieurs soft forks sont en discussion, et le dépôt montre où en est chacun. Aucun ne dispose de paramètres d’activation pour le réseau principal dans une version publiée de Bitcoin Core au 9 novembre 2026, et aucun n’est programmé.
| BIP | Ce qu’il ferait | Statut dans le dépôt |
|---|---|---|
| BIP 54, Consensus Cleanup (Antoine Poinsot, Matt Corallo) | Corrige le bug du timewarp, plafonne le temps de validation d’un bloc dans le pire cas, rend invalides les transactions de 64 octets, empêche les transactions en double | Complete |
| BIP 119, CHECKTEMPLATEVERIFY (Jeremy Rubin) | Nouvel opcode qui engage à l’avance les sorties de la transaction qui dépensera une pièce | Draft |
| BIP 348, CHECKSIGFROMSTACK (Brandon Black, Jeremy Rubin) | Opcode de tapscript qui vérifie une signature sur des données arbitraires | Draft |
| BIP 347, OP_CAT dans tapscript (Ethan Heilman, Armin Sabouri) | Rétablit la concaténation d’éléments de la pile dans tapscript, avec une limite de 520 octets | Complete (depuis le 1er mars 2026) |
| BIP 360, Pay-to-Merkle-Root (P2MR) | Nouveau type de sortie comme Taproot mais sans chemin par clé, en défense contre de futures attaques quantiques | Draft |
| BIP 361, Post Quantum Migration and Legacy Signature Sunset (Jameson Lopp et autres) | Fin progressive de l’envoi vers, puis de la dépense depuis, des sorties vulnérables au quantique | Draft (Informational) |
Source : en-têtes de chaque BIP du dépôt bitcoin/bips, lus le 9 novembre 2026.
Le plus avancé est le BIP 54. Ses auteurs disent que regrouper plusieurs correctifs amortit le coût fixe du déploiement d’un soft fork, et la limite de 2 500 opérations de signature que Bitcoin Core 30.0 a ajoutée à sa politique de relais a été introduite, selon les notes de version, pour préparer un éventuel déploiement du BIP 54. Une demande de fusion qui l’implémente « sans activation sur le réseau principal » a été ouverte dans Bitcoin Core le 24 juillet 2026 et était toujours ouverte le 9 novembre 2026. Le calendrier d’activation relève d’estimations personnelles, non d’un plan.
Les propositions quantiques sont les plus contestées. Le BIP 361 ne vit pas seul : il suivrait l’adoption d’un type de sortie post-quantique, pas encore spécifié, et sa première phase interdirait l’envoi de fonds vers des adresses vulnérables au quantique. Frederic Fosco, cofondateur d’OP_NET, a déclaré à Decrypt en avril 2026 qu’un gel imposé par le protocole « est une confiscation, point final » (traduction) ; Lopp, cité dans le même article, a dit de sa proposition : « Je l’ai écrite parce que j’aime encore moins l’alternative » (traduction). CTV et CHECKSIGFROMSTACK sont souvent évoqués ensemble comme un paquet de covenants, avec partisans et opposants sur la liste de diffusion et sur delvingbitcoin.org. Chaque proposition aurait aussi besoin de sa propre méthode d’activation.
Les correctifs de sécurité n’exigent pas de soft fork
Tout ne passe pas par cette mécanique. Les corrections de bugs qui ne touchent pas au consensus sont publiées comme n’importe quelle mise à jour logicielle, et les opérateurs les installent ou non. Le 22 octobre 2026, Bitcoin Core a fusionné la demande n° 1281 de son site web, qui ajoute à sa politique de sécurité une classe de bugs « facilement découvrables » : les bugs que l’on peut trouver avec un effort minimal, par exemple une simple requête à un modèle d’IA, sont corrigés dans toutes les versions maintenues et divulgués immédiatement, sans l’embargo des niveaux Low, Medium, High et Critical. Notre article sur la nouvelle politique de divulgation en donne le détail.
Bitcoin Core 32.0 a suivi le 27 octobre 2026, et la page de cycle de vie du projet donne la même date pour la fin de vie des versions 29.x : les lignes maintenues sont donc désormais 32.x, 31.x et 30.x. Comme Bitcoin Core ne se met jamais à jour tout seul, les vieilles versions restent en service : dans l’exploration du 18 octobre étudiée dans notre article sur les nœuds périmés, environ quatre nœuds Bitcoin Core joignables sur dix faisaient tourner des lignes que le projet ne corrigeait plus. Non maintenu ne veut pas dire compromis, mais les correctifs n’arrivent plus sur ces machines.
Ce que la gouvernance de Bitcoin change pour les détenteurs et les opérateurs de nœuds
Pour un détenteur qui garde ses pièces sur une plateforme ou dans un portefeuille sans nœud, l’essentiel se passe hors de vue. Votre dépositaire ou fournisseur de portefeuille décide du logiciel qu’il utilise et, lors d’une scission contestée, de la chaîne qu’il crédite. Les soft forks comme SegWit et Taproot n’ont exigé aucune action des détenteurs : les anciennes adresses ont continué de fonctionner, et les nouvelles fonctions étaient facultatives.
Pour un opérateur de nœud, le logiciel choisi est une prise de position sur la politique et, lors d’un soft fork contesté, il peut décider de la chaîne que l’on suit. Faire tourner Bitcoin Core ou Knots, régler -datacarriersize ou garder la valeur par défaut sont des choix légitimes, et notre guide pas à pas pour faire tourner un nœud Bitcoin couvre l’installation. Avant d’installer une version qui applique de nouvelles règles de consensus, lisez quelles règles elle ajoute, à partir de quel bloc, et ce qui se passe si la plupart des mineurs ne suivent pas : les nœuds BIP-110 d’août 2026 se sont retrouvés sur une chaîne que presque personne d’autre n’utilisait. Garder son logiciel sur une ligne maintenue est l’autre habitude qui compte.
Les scissions soulèvent aussi des questions fiscales, que le guide des forks traite pour les États-Unis (Revenue Ruling 2019-24 de l’IRS, en anglais) et le Royaume-Uni. L’épisode BIP-110 n’a laissé que quelques blocs sur une chaîne arrêtée et aucune pièce négociée connue. En France, le questions-réponses de impots.gouv.fr mis à jour le 17 juillet 2026 indique un prélèvement forfaitaire unique de 31,4 % sur les plus-values de cession d’actifs numériques de 2026 ; notre guide de la fiscalité des cryptos en France présente les règles générales.
La prochaine date à surveiller n’est pas une hauteur de bloc. C’est le moment où une version de Bitcoin Core, ou d’un autre client, livrera des paramètres d’activation sur le réseau principal pour l’une des propositions ci-dessus. D’ici là, elles restent des documents et des demandes de fusion.
