BIP Bitcoin : comment fonctionnent les propositions d'amélioration du protocole

BitcoinBitcoinPremiere cryptomonnaie decentralisee, creee en 2009 par Satoshi Nakamoto. évolue. Pas au rythme d’une startup qui publie une nouvelle version tous les mois, mais lentement, prudemment, avec des débats qui durent parfois des années. Chaque modification du protocole suit un processus structuré : les Bitcoin Improvement Proposals - les BIP.

Comprendre les BIP, c’est comprendre comment Bitcoin se gouverne sans PDG, sans conseil d’administration et sans autorité centrale. Un système où personne ne commande mais où les changements doivent convaincre des milliers de développeurs et d’opérateurs de noeuds répartis sur toute la planète.

Qu’est-ce qu’un BIP

Un BIP (Bitcoin Improvement Proposal) est un document technique qui décrit une modification proposée du protocole Bitcoin. C’est le format standard pour soumettre une idée à la communauté, expliquer pourquoi elle est nécessaire et comment la mettre en oeuvre.

Le concept vient du monde du développement logiciel. Python a ses PEP (Python Enhancement Proposals), Bitcoin a ses BIP. Même structure, même logique : centraliser la discussion autour d’un document de référence plutôt que de laisser les débats se disperser sur des forums et des messageries.

Le premier BIP officiel - BIP-0001 - a été rédigé en 2011 par Amir Taaki. Il définit justement ce qu’est un BIP et comment en rédiger un. Meta, mais nécessaire : avant BIP-0001, il n’y avait aucun processus formalisé pour proposer des changements.

À quoi sert un BIP

Un BIP remplit trois rôles :

Documentation technique. Le BIP décrit précisément le changement proposé. Pas de flou, pas d’approximation. Les développeurs qui liront le document doivent pouvoir implémenter la modification sans avoir à deviner ce que l’auteur avait en tête.

Point de coordination. Un BIP centralise la discussion. Au lieu d’avoir 15 fils de conversation éparpillés sur Reddit, Twitter et les listes de diffusion email, la communauté se réfère à un document unique. Les commentaires, les critiques et les améliorations s’accumulent autour de ce texte.

Archive historique. Quand un BIP est adopté, il devient la référence pour comprendre pourquoi telle fonctionnalité existe et comment elle a été conçue. SegWit ? BIP-141. Taproot ? BIP-340, 341 et 342. C’est la mémoire technique de Bitcoin.

Le processus de vie d’un BIP

Un BIP ne se réveille pas un matin avec le statut “Définitif”. Il traverse plusieurs étapes, chacune avec ses critères de validation.

Draft : le brouillon initial

L’auteur rédige un premier jet. Structuré selon un template précis : résumé, motivation, spécification technique, compatibilité rétroactive, implémentation de référence. À ce stade, le BIP n’est pas encore soumis officiellement. L’auteur peut le partager sur les listes de diffusion (comme bitcoin-dev) pour recevoir des premiers retours.

Proposed : soumission officielle

Le BIP est publié dans le dépôt GitHub bitcoin/bips avec un numéro attribué par les éditeurs (actuellement Luke Dashjr et quelques autres contributeurs historiques). Le document est ouvert aux commentaires. Les développeurs pointent les incohérences, suggèrent des améliorations, posent des questions techniques.

Cette phase peut durer des mois ou des années. BIP-141 (SegWit) a été proposé en décembre 2015 et activé en août 2017 après presque deux ans de débats.

Implemented : code fonctionnel

Un développeur (souvent l’auteur du BIP lui-même) écrit le code qui implémente la proposition. Ce code est testé sur des réseaux expérimentaux comme testnet ou signet. D’autres développeurs vérifient que l’implémentation correspond bien à la spécification.

Final : adopté par le réseau

Le BIP est activé sur le mainnet. Les noeuds qui ont mis à jour leur logiciel appliquent les nouvelles règles. À partir de là, le BIP devient une référence figée. Toute modification ultérieure nécessite un nouveau BIP.

Rejected ou Withdrawn : rejet ou abandon

Un BIP peut être rejeté si la communauté considère qu’il pose plus de problèmes qu’il n’en résout. Il peut aussi être retiré par son auteur s’il constate que l’idée n’a pas d’avenir. Ces échecs font partie du processus : mieux vaut un BIP rejeté qu’une modification bancale déployée en production.

Les trois types de BIP

Tous les BIP ne visent pas le même objectif. La communauté les classe en trois catégories.

Standards Track : modifications du protocole

Les BIP de type Standards Track touchent directement au fonctionnement de Bitcoin. Ils modifient les règles de consensus, ajoutent des fonctionnalités au langage de script ou changent la structure des transactions.

Exemples notables :

• BIP-141 (SegWit) : sépare les signatures des données de transaction
• BIP-340 (Schnorr) : remplace ECDSA par des signatures plus compactes
• BIP-341 (Taproot) : améliore la confidentialité des transactions complexes

Ces BIP nécessitent un consensus fort. Si une partie du réseau ne met pas à jour, il y a risque de fork - une séparation du réseau en deux chaînes incompatibles.

Informational : documentation et recommandations

Les BIP informationnels ne modifient rien au protocole. Ils documentent des pratiques, expliquent des concepts ou donnent des recommandations. BIP-39, qui décrit comment générer une seed phraseSeed PhraseSuite de 12 ou 24 mots qui permet de recuperer l'acces a un wallet crypto en cas de perte. à partir de mots anglais, en est un exemple.

Ces BIP n’ont pas besoin de consensus. Ils servent de référence commune pour les développeurs de walletsWalletPortefeuille numerique qui stocke vos cles privees et permet d'envoyer et recevoir des cryptomonnaies. ou d’applications. Chacun est libre de les suivre ou non, mais en pratique, respecter ces standards facilite l’interopérabilité.

Process : gouvernance et procédures

Les BIP de processus touchent aux règles de fonctionnement de la communauté Bitcoin elle-même. BIP-0001, qui définit ce qu’est un BIP, est un Process BIP. BIP-0002, qui décrit le workflow complet d’un BIP, en est un autre.

Ces BIP évoluent rarement. Une fois qu’un processus fonctionne, la communauté évite de le modifier sans raison solide.

SegWit : le BIP qui a changé Bitcoin

Segregated Witness (SegWit) est probablement le BIP le plus débattu de l’histoire de Bitcoin. Proposé en décembre 2015, activé en août 2017 après presque deux ans de controverses.

Le problème de la malléabilité des transactions

Avant SegWit, les identifiants de transaction (TXID) incluaient les signatures. Un attaquant pouvait modifier légèrement une signature sans invalider la transaction, ce qui changeait le TXID. Ça créait des complications pour des fonctionnalités avancées comme le Lightning Network, qui repose sur des chaînes de transactions liées.

SegWit résout ce problème en séparant les signatures (witness data) du reste de la transaction. Le TXID ne dépend plus des signatures, ce qui rend impossible de le modifier après coup.

Plus de place dans les blocs

Effet secondaire bienvenu : en retirant les signatures du calcul de la taille de bloc, SegWit augmente de facto la capacité. Un bloc de 1 Mo peut désormais contenir l’équivalent de 2 à 2,7 Mo de transactions selon leur type.

Les chiffres parlent. En janvier 2017, avant SegWit, Bitcoin traitait environ 250 000 transactions par jour. En 2024, avec plus de 95 % des transactions utilisant SegWit, le réseau dépasse régulièrement 600 000 transactions quotidiennes.

Un soft fork controversé

SegWit a été implémenté comme un soft fork - une modification rétrocompatible. Les anciens noeuds continuent de fonctionner, ils ignorent simplement les nouvelles règles. Ça évite de forcer tout le monde à mettre à jour en même temps.

Mais cette approche a créé des tensions. Une partie de la communauté voulait un hard fork pour augmenter directement la taille des blocs à 2 Mo ou plus. Le débat a mené au fork de Bitcoin Cash en août 2017. Bitcoin a gardé SegWit, Bitcoin Cash a opté pour des blocs plus gros.

Taproot : confidentialité et scripts avancés

Taproot est le BIP le plus ambitieux depuis SegWit. Activé en novembre 2021 au bloc 709 632, il combine trois propositions : BIP-340 (signatures Schnorr), BIP-341 (MAST) et BIP-342 (Tapscript).

Signatures Schnorr (BIP-340)

Bitcoin utilisait jusqu’ici ECDSA pour les signatures. Schnorr apporte plusieurs avantages :

Taille réduite. Une signature Schnorr fait 64 octets contre 71-72 pour ECDSA. Ça économise de l’espace, donc réduit les frais.

Agrégation de signatures. Avec Schnorr, plusieurs signatures peuvent être combinées en une seule. Une transaction multi-signature 3-sur-5 ressemble à une transaction simple. Meilleure confidentialité, moins d’espace utilisé.

Sécurité mathématique plus solide. Schnorr repose sur des propriétés mathématiques prouvées depuis des décennies. ECDSA était suffisant, Schnorr est meilleur.

MAST : Merkelized Abstract Syntax Trees (BIP-341)

Les transactions Bitcoin complexes (multi-signatures, time-locks, conditions diverses) exposent toutes leurs conditions sur la blockchainBlockchainRegistre numerique decentralise et infalsifiable qui enregistre des transactions dans des blocs enchaines.. Même celles qui ne sont jamais utilisées.

MAST change ça. Il structure les conditions sous forme d’arbre de Merkle. Seule la condition exécutée est révélée. Les autres restent cachées. Résultat : transactions plus légères, meilleure confidentialité.

Tapscript (BIP-342)

Tapscript est une mise à jour du langage de script de Bitcoin. Il facilite l’ajout de nouvelles fonctionnalités sans casser la compatibilité. C’est une fondation pour les évolutions futures, comme les signatures seuil ou les contrats plus avancés.

Comment un BIP devient réalité

Écrire un BIP ne suffit pas. Il faut convaincre la communauté que le changement en vaut la peine. Et dans Bitcoin, convaincre la communauté prend du temps.

Discussion publique

L’auteur publie son BIP sur la liste de diffusion bitcoin-dev. Les développeurs expérimentés posent des questions, pointent des failles potentielles, suggèrent des alternatives. Cette phase peut durer des mois. Certains BIP meurent ici, faute d’intérêt ou parce que les arguments ne tiennent pas.

Implémentation de référence

Si le BIP survit aux premières critiques, un développeur (souvent l’auteur) écrit le code. Cette implémentation est testée sur testnet, un réseau Bitcoin expérimental où l’on peut casser des choses sans conséquence.

D’autres développeurs vérifient le code. Ils cherchent des bugs, testent des cas limites, s’assurent que l’implémentation respecte la spécification. Ce processus de revue de code est critique : Bitcoin gère des centaines de milliards de dollars, une erreur coûterait cher.

Activation coordonnée

Pour les modifications de consensus (les Standards Track BIP), l’activation nécessite un mécanisme de coordination. Le plus courant : le “signaling” des mineurs. Les mineurs qui soutiennent le BIP l’indiquent dans les blocs qu’ils produisent. Quand un seuil (souvent 90 ou 95 %) est atteint sur une période donnée, le BIP s’active automatiquement.

Ce mécanisme évite une activation chaotique où une partie du réseau applique les nouvelles règles et l’autre non. Tout le monde bascule au même moment.

La gouvernance Bitcoin : pas de patron, pas de vote

Bitcoin n’a pas de CEO. Pas de conseil d’administration. Pas de vote à main levée pour décider d’une modification. Ce qui ressemble à du chaos est en réalité un système de gouvernance par consensus approximatif.

Rough consensus : le consensus approximatif

Le principe vient de l’IETF, l’organisation qui standardise les protocoles Internet. Rough consensus ne veut pas dire unanimité. Ça veut dire que les objections majeures ont été traitées et qu’aucune faction importante ne bloque la proposition.

Dans Bitcoin, ça se traduit par : si un BIP est largement soutenu par les développeurs, implémenté dans les logiciels principaux (Bitcoin Core, btcd, etc.) et adopté par les opérateurs de noeuds sans opposition massive, il passe.

Le rôle des différents acteurs

Les développeurs écrivent les BIP et le code. Mais ils ne décident pas. Un développeur peut écrire un BIP brillant qui sera rejeté si les autres acteurs ne le soutiennent pas.

Les opérateurs de noeuds valident les blocs selon les règles du protocole. Ce sont eux qui “votent” en choisissant quelle version du logiciel faire tourner. Pas de mise à jour, pas d’adoption du BIP.

Les mineurs sécurisent le réseau et signalent leur soutien aux BIP. Mais ils ne peuvent pas forcer un changement. Si les noeuds refusent un BIP, les blocs des mineurs qui l’appliquent seront rejetés.

Les utilisateurs détiennent des bitcoins et font tourner des wallets. Leur pouvoir est indirect : s’ils désapprouvent massivement un changement, ils peuvent vendre leurs BTC ou migrer vers une version forkée du protocole. Le market cap de Bitcoin Cash vs Bitcoin montre bien qui a gagné ce débat.

Pourquoi c’est lent et pourquoi c’est voulu

Bitcoin évolue lentement. SegWit a pris presque deux ans. Taproot, environ trois ans. C’est frustrant quand on vient du monde des startups où on déploie en continu.

Mais cette lenteur est une fonctionnalité, pas un bug. Bitcoin gère plus de 1 000 milliards de dollars de valeur. Une erreur dans le code, un changement mal pensé, et c’est des milliards qui disparaissent. La prudence est rationnelle.

Les protocoles Internet (TCP/IP, HTTP, TLS) évoluent aussi lentement. Ce sont des infrastructures critiques. Bitcoin est dans la même catégorie : une fondation sur laquelle on construit d’autres choses. La stabilité prime sur la vitesse.

Soft fork vs hard fork : les deux types de mise à jour

Tous les BIP ne sont pas égaux en termes de compatibilité. Certains sont rétrocompatibles (soft fork), d’autres non (hard fork).

Soft fork : compatibilité préservée

Un soft fork resserre les règles du protocole. Les anciens noeuds continuent de fonctionner, ils considèrent simplement que les nouvelles transactions sont valides selon leurs anciennes règles.

SegWit est un soft fork. Un noeud qui n’a pas mis à jour voit les transactions SegWit comme des transactions “anyone-can-spend” - n’importe qui peut dépenser ces fonds selon l’ancien protocole. Mais les noeuds à jour appliquent les nouvelles règles qui protègent ces fonds. Résultat : pas de split du réseau.

Hard fork : incompatibilité totale

Un hard fork élargit les règles ou les change de façon incompatible. Les anciens noeuds rejettent les blocs produits selon les nouvelles règles. Si une partie du réseau refuse de mettre à jour, la blockchain se divise en deux chaînes distinctes.

Bitcoin Cash (août 2017) est un hard fork. EthereumEthereumBlockchain programmable qui permet de creer des smart contracts et des applications decentralisees. Classic (juillet 2016) aussi, après le hack de The DAODAOOrganisation autonome decentralisee geree par ses membres via des votes on-chain et des smart contracts.. Ces événements créent deux cryptomonnaies séparées avec des communautés et des marchés distincts.

Les soft forks sont préférés dans Bitcoin parce qu’ils préservent l’unité du réseau. Mais ils ne permettent pas tous les types de changements. Augmenter la taille des blocs de 1 Mo à 2 Mo nécessite un hard fork - les anciens noeuds rejetteraient les blocs trop gros. C’est ce débat qui a mené à Bitcoin Cash.

BIP notables : au-delà de SegWit et Taproot

SegWit et Taproot sont les plus connus, mais d’autres BIP ont façonné Bitcoin.

BIP-32 : portefeuilles déterministes hiérarchiques (HD)

Avant BIP-32 (proposé en 2012), chaque adresse Bitcoin nécessitait une sauvegarde séparée. Vous génériez 100 adresses, vous deviez sauvegarder 100 clés privées. Perdre une sauvegarde = perdre les fonds associés.

BIP-32 introduit les HD wallets. Une seule seed (graine) génère une infinité d’adresses selon un arbre déterministe. Vous sauvegardez la seed, vous pouvez recréer toutes vos adresses. Les wallets modernes (Ledger, Trezor, Electrum) utilisent tous BIP-32.

BIP-39 : phrases mnémoniques

BIP-39 transforme la seed en une liste de mots anglais. Au lieu de sauvegarder une chaîne hexadécimale de 256 bits, vous notez 12 ou 24 mots. Plus facile à lire, moins d’erreur de frappe, meilleure expérience utilisateur.

Ces mots sont tirés d’une liste standardisée de 2 048 mots. “abandon ability able about above absent absorb abstract absurd abuse access accident…” Si vous perdez votre hardware wallet, vous rentrez ces mots dans un nouveau wallet et récupérez l’accès à vos fonds.

BIP-44 : structure de dérivation multi-comptes

BIP-44 définit comment organiser les adresses dérivées d’une seed. Il permet de gérer plusieurs cryptomonnaies et plusieurs comptes à partir d’une seule seed. Votre Ledger peut gérer Bitcoin, Ethereum et Litecoin avec une seule phrase de récupération grâce à BIP-44.

BIP-141, 143, 144 : l’ensemble SegWit

SegWit n’est pas un seul BIP. BIP-141 définit la structure globale, BIP-143 spécifie le nouveau format de signature et BIP-144 décrit comment les noeuds propagent les transactions SegWit. Ces trois BIP forment un tout cohérent.

Les BIP en discussion : ce qui pourrait changer Bitcoin

Plusieurs BIP sont actuellement en phase de discussion ou d’implémentation. Ils ne sont pas encore activés, mais ils donnent une idée des directions futures.

BIP-324 : chiffrement des communications entre noeuds

Actuellement, les noeuds Bitcoin communiquent en clair. N’importe qui qui observe le trafic réseau peut voir quelles transactions sont diffusées par quel noeud. BIP-324 propose de chiffrer ces communications pour améliorer la vie privée au niveau réseau.

BIP-119 : CHECKTEMPLATEVERIFY (CTV)

CTV est un nouvel opcode qui permet de restreindre comment des bitcoins peuvent être dépensés. Ça ouvre la porte à des “covenants” - des conditions programmables sur les transactions futures. Utile pour des contrats plus avancés, mais controversé car ça change la nature de Bitcoin en tant que “cash numérique”.

BIP-??? : réactiver OP_CAT

OP_CAT est un ancien opcode désactivé en 2010 par Satoshi lui-même, par prudence. Il permettait de concaténer des chaînes de données, ce qui ouvrait des possibilités de scripts plus complexes. Certains développeurs veulent le réactiver dans une version sécurisée pour permettre des fonctionnalités avancées.

Comment suivre l’actualité des BIP

Les BIP ne font pas la une des journaux crypto - sauf quand ils créent une controverse comme SegWit. Mais si vous voulez suivre l’évolution technique de Bitcoin, voici où chercher.

Le dépôt GitHub bitcoin/bips. C’est la source officielle. Tous les BIP y sont publiés avec leur historique de modifications. Vous pouvez suivre les pull requests pour voir les nouveaux BIP proposés.

La liste de diffusion bitcoin-dev. Les développeurs débattent des BIP sur cette mailing list hébergée par le Linux Foundation. Les discussions sont techniques mais publiques. Vous pouvez lire les archives sans vous inscrire.

Bitcoin Optech Newsletter. Une newsletter hebdomadaire qui résume l’actualité technique de Bitcoin. Quand un BIP important progresse, Optech en parle. Gratuit, sans pub, écrit par des experts.

Les Bitcoin Core release notes. Quand une nouvelle version de Bitcoin Core sort, les notes de version détaillent quels BIP sont implémentés. C’est un bon indicateur de ce qui va bientôt être activé sur le réseau.

Pourquoi les BIP rendent Bitcoin antifragile

Le système BIP est lent, parfois frustrant, souvent source de débats houleux. Mais c’est précisément cette friction qui rend Bitcoin robuste.

Pas de décision centrale. Personne ne peut forcer un changement. Satoshi lui-même ne pourrait plus modifier Bitcoin aujourd’hui - il devrait convaincre la communauté comme n’importe qui.

Transparence totale. Chaque BIP est public. Les discussions aussi. Les revues de code sont ouvertes. N’importe qui peut participer ou simplement observer. Cette transparence filtre les mauvaises idées.

Résistance aux modes. Les développeurs Bitcoin ne suivent pas les tendances. Smart contractsSmart ContractProgramme autonome deploye sur une blockchain qui s'execute automatiquement quand des conditions sont remplies. sur Ethereum ? Bitcoin reste focalisé sur l’argent numérique. NFTNFTToken non fongible : certificat numerique unique sur blockchain prouvant la propriete d'un actif digital. sur Solana ? Bitcoin continue d’optimiser les transactions. Cette discipline évite les erreurs stratégiques.

Réversibilité impossible. Une fois un BIP activé, on ne revient pas en arrière facilement. Ça force la communauté à bien réfléchir avant de déployer. Pas de “on verra après si ça marche”.

Les systèmes dirigés par une entreprise évoluent vite mais cassent souvent. Bitcoin évolue lentement mais ne casse jamais. 15 ans sans downtime, sans hack du protocole, sans modification forcée. C’est unique dans l’histoire des systèmes informatiques.

Les BIP dans le contexte plus large de Bitcoin

Les BIP ne sont qu’une pièce du puzzle. Bitcoin évolue aussi via d’autres mécanismes.

Bitcoin Core. Le logiciel de référence. Même sans BIP officiel, les développeurs de Core peuvent inclure des améliorations. Par exemple, des optimisations de performance, des corrections de bugs ou des améliorations de l’interface RPC. Ces changements ne touchent pas au consensus, donc ne nécessitent pas de BIP.

Les logiciels alternatifs. Bitcoin Core n’est pas le seul. Il existe btcd (en Go), Bitcoin Knots (un fork de Core avec plus de fonctionnalités), et d’autres implémentations. Ces clients suivent les BIP pour rester compatibles avec le réseau.

Le Lightning Network. Lightning a ses propres propositions d’amélioration (BOLT - Basis of Lightning Technology). Ces spécifications évoluent indépendamment des BIP Bitcoin, mais respectent les contraintes imposées par le protocole de base.

Bitcoin est une base stable sur laquelle on construit des surcouches innovantes. Les BIP maintiennent cette base solide pendant que Lightning, RGB, Liquid et d’autres projets explorent de nouvelles possibilités.

Comprendre les BIP, c’est comprendre que Bitcoin n’est pas figé mais qu’il évolue à son rythme - un rythme dicté par la nécessité de ne jamais casser la confiance de ceux qui y stockent leur épargne.