BIPs Bitcoin : processus, BIP 32/39/44, 86, 118, 119, 300

Les Bitcoin Improvement Proposals, abrégés BIP, sont le mécanisme par lequel Bitcoin évolue depuis 2011. Amir Taaki a publié BIP 1 cette année-là pour formaliser un cadre inspiré des PEP Python et des RFC IETF. Au lieu d'un comité directeur, Bitcoin utilise un processus public où n'importe qui peut proposer une modification, documentée dans un BIP, et où l'adoption se fait par implémentation volontaire dans les logiciels et signaling des mineurs.

Le résultat fin 2026 est un corpus de plus de 400 BIPs. Une poignée structure le quotidien sans que personne ne le sache : BIP 32/39/44 derrière chaque seed phrase, BIP 21 derrière chaque QR code Bitcoin, BIP 174 derrière chaque PSBT, BIP 327 derrière chaque MuSig2. D'autres sont au cœur des débats du moment : BIP 118 ANYPREVOUT pour Lightning, BIP 119 CTV pour les covenants, BIP 300 pour les Drivechains, BIP 345 pour OP_VAULT.

Cet article explique d'abord le processus BIP et ses statuts, puis passe en revue 10 BIPs structurants en deux groupes : ceux déjà activés qu'on utilise sans le savoir, et ceux en discussion qui détermineront les prochains soft-forks. Lecture pour qui veut suivre les débats Bitcoin sans dépendre des résumés journalistiques.

Le processus BIP et ses statuts

Tout commence sur la mailing list bitcoin-dev ou sur Delving Bitcoin (forum technique successeur depuis 2023). Quelqu'un poste une idée, le débat technique l'affine pendant des semaines ou des mois. Si l'idée tient le choc, l'auteur rédige un BIP formel selon le template défini par BIP 2 (révision de BIP 1 par Luke Dashjr en 2016) et soumet une pull request sur le dépôt bitcoin/bips. Un BIP champion (un éditeur reconnu) attribue un numéro.

Le BIP passe ensuite par des statuts. Draft : version initiale, encore en discussion. Proposed : maturation technique atteinte, prête à implémentation. Active ou Final : largement implémenté et utilisé (Active pour les processus informationnels, Final pour les changements de protocole). Replaced ou Withdrawn : remplacé par un BIP plus récent ou retiré par son auteur. Rejected : explicitement écarté par consensus.

Un BIP de changement de protocole (consensus change) demande en plus un soft-fork ou un hard-fork. La voie historique pour les soft-forks est BIP 9 (signaling miner par version bits), BIP 8 (signaling avec activation forcée au flag day), ou Speedy Trial (variante utilisée pour Taproot). Aucune voie n'est figée : chaque soft-fork négocie sa propre méthode d'activation. C'est la grande différence entre Bitcoin et Ethereum : pas de roadmap centrale, juste des BIPs qui montent ou tombent selon le consensus distribué.

BIP 32/39/44 : la fondation des wallets modernes

BIP 32 (Pieter Wuille, 2012) définit les Hierarchical Deterministic Wallets : à partir d'une seule graine cryptographique (la seed), un wallet peut dériver de manière déterministe une infinité de paires clé privée/publique organisées en arbre. La conséquence opérationnelle est qu'une seule sauvegarde de seed suffit à restaurer tout un wallet, peu importe combien d'adresses ont été utilisées.

BIP 39 (Trevor Perrin, Marek Palatinus, Pavol Rusnak, 2013) ajoute le mécanisme des 12 ou 24 mots mnémoniques pour encoder cette seed sous forme humainement notable. Une liste de 2 048 mots anglais standardisés, plus un checksum, permet d'écrire la seed sur du papier ou de la frapper sur un steel plate. La passphrase BIP 39 optionnelle ajoute un 13ème (ou 25ème) mot personnalisé qui fonctionne comme un mot de passe additionnel.

BIP 44 (Marek Palatinus, Pavol Rusnak, 2014) propose une convention de chemins de dérivation organisés en cinq niveaux : m/44'/0'/0'/0/0 pour Bitcoin, m/44'/60'/0'/0/0 pour Ethereum, etc. C'est cette convention qui permet à un même seed BIP 39 de servir pour plusieurs cryptos sans conflit. Les BIPs 49 (P2SH-SegWit), 84 (Native SegWit bc1q), 86 (Taproot bc1p) sont des variantes spécifiques à chaque type d'adresse. Ensemble, ces quatre BIPs sont la fondation technique de quasiment tous les wallets Bitcoin modernes.

BIPs invisibles de l'UX : 21, 174, 327

BIP 21 (Nils Schneider, 2012) définit l'URI Bitcoin standard : bitcoin:bc1q.../?amount=0.001&label=Coffee&message=... Cette URI est ce que tous les wallets scannent dans un QR code. Sans BIP 21, chaque wallet aurait sa propre convention et les paiements croisés ne marcheraient pas. Le succès de BIP 21 est tel qu'on ne le voit plus : il est partout, comme HTTP pour le web.

BIP 174 (Andrew Chow, 2017) introduit les Partially Signed Bitcoin Transactions (PSBT) : un format standardisé pour décrire une transaction Bitcoin partiellement signée, transférable entre wallets et hardware wallets sans risque. C'est ce qui rend possible un multisig 2-of-3 où Alice signe sur son hardware, exporte la PSBT vers une clé USB, la passe à Bob qui signe à son tour et diffuse. Sparrow, Specter, Bitcoin Core, Trezor, Ledger, Coldcard supportent tous PSBT. Sans BIP 174, le multisig moderne n'existerait pas dans sa forme actuelle.

BIP 327 (Jonas Nick, Tim Ruffing, Yannick Seurin, 2023) standardise MuSig2, l'agrégation de signatures Schnorr discutée dans l'article Taproot. Promu Final en 2024, BIP 327 est désormais implémenté dans libsecp256k1 et utilisé par Casa, Unchained, Liana, Sparrow et Specter pour les multisigs modernes confidentiels. C'est l'exemple type d'un BIP qui rend un changement protocolaire (Taproot) réellement utilisable côté applications.

BIP 118 ANYPREVOUT : pour Lightning de nouvelle génération

BIP 118 (Christian Decker, Anthony Towns, 2017, draft à Proposed en 2022) propose un nouveau flag de signature SIGHASH_ANYPREVOUT (et son corollaire SIGHASH_ANYPREVOUTANYSCRIPT). Idée : permettre à une signature de ne pas être liée à un output spécifique, mais à n'importe quel output qui satisfait une condition donnée. C'est un changement subtil mais fondamental pour la classe des contrats où la même signature doit pouvoir s'appliquer à plusieurs versions d'une transaction.

L'application phare est Eltoo, une refonte de Lightning Network proposée par Decker, Russell et Osuntokun en 2018. Aujourd'hui, un canal Lightning utilise des transactions de pénalité pour décourager la triche (publier un état ancien). Eltoo simplifie radicalement : avec ANYPREVOUT, on remplace la pénalité par une simple « override » où le dernier état toujours gagne. Plus de penalty, plus de risque de perte si on rate la fenêtre de réaction, plus de besoin de watchtowers pour la majorité des cas.

BIP 118 est en discussion active en 2026 mais n'a pas encore reçu de chemin clair vers l'activation. Les développeurs Lightning (en particulier Decker et l'équipe ACINQ) le poussent depuis plusieurs années. La résistance vient principalement du fait que d'autres BIPs (CTV, OP_VAULT) sont aussi dans la file, et qu'il faut choisir quel soft-fork passe en premier. Probable activation 2027-2028 si consensus se forme.

BIP 119 CTV et BIP 345 OP_VAULT : les covenants

Un covenant en Bitcoin est une contrainte qui s'attache à un output et qui restreint comment cet output peut être dépensé dans le futur. Aujourd'hui, Bitcoin ne supporte pas les covenants : une fois qu'une signature autorise une dépense, le destinataire peut envoyer les fonds n'importe où sans restriction. Les covenants ouvriraient une nouvelle classe de contrats : coffres avec délai de retrait obligatoire, pools de paiement type Ark, etc.

BIP 119 (Jeremy Rubin, 2020) propose OP_CHECKTEMPLATEVERIFY (CTV) comme le covenant minimal : un output peut exiger que la transaction qui le dépense ait une forme exacte préalablement spécifiée (mêmes outputs, mêmes montants, mêmes locktimes). CTV est le covenant le plus simple et le moins controversé techniquement, mais le débat sur son intérêt vs ses risques est intense depuis 2021. Jeremy Rubin a quitté le projet en 2023, le BIP 119 reste vivant porté par d'autres contributeurs.

BIP 345 (James O'Beirne, Greg Sanders, 2023) propose OP_VAULT comme un covenant plus structuré dédié aux coffres time-locked : une dépense doit passer par un délai d'attente paramétrable, pendant lequel le propriétaire peut annuler via une clé de recouvrement. C'est l'outil rêvé pour la garde institutionnelle et pour les particuliers qui veulent une protection forte contre le vol de clé. BIP 345 est encore en Draft fin 2026, en discussion sur Delving Bitcoin. Le consensus sur la séquence covenants (CTV avant OP_VAULT, ou les deux ensemble, ou aucun) reste à former.

BIP 300 Drivechains et lecture critique des BIPs

BIP 300 (Paul Sztorc, 2017) propose les Drivechains : un mécanisme permettant à Bitcoin de servir de couche de règlement pour des sidechains spécialisées, où l'ancrage et le retrait des fonds depuis la sidechain sont validés directement par les mineurs Bitcoin (via miner-activated peg-out). C'est techniquement le plus ambitieux des BIPs en discussion, et le plus controversé : ses détracteurs (notamment Adam Back et la communauté Blockstream) considèrent qu'il introduit un risque de centralisation des mineurs et altère les incitations économiques de Bitcoin.

Le BIP 300 a oscillé entre Draft et Withdrawn pendant des années. En 2025-2026, plusieurs propositions de modification (BIP 301 pour le bloc merge-mined, variantes BIP-Drivechain-Lite) tentent de relancer le débat. L'activation reste improbable à court terme, mais le BIP 300 cristallise une discussion plus large sur le rôle des sidechains dans l'écosystème (à mettre en regard avec Liquid Network, traité dans un autre article du thème).

Lecture critique des BIPs. Suivre les BIPs sérieusement demande quelques réflexes. Lire le BIP lui-même, pas seulement les résumés (le texte standard est court et lisible). Lire les commentaires de la pull request originale sur github.com/bitcoin/bips. Suivre les discussions sur Delving Bitcoin et bitcoin-dev. Méfiance vis-à-vis des comptes Twitter qui résument un BIP en une thread enthousiaste : un BIP en discussion est rarement aussi simple que ce qu'un fil de 280 caractères en dit. Bitcoin Optech (newsletter hebdomadaire) reste la meilleure source pour qui veut suivre la queue des BIPs activement.

Avertissement

Contenu éducatif et informatif uniquement : ni conseil en investissement, ni conseil fiscal ou juridique. Bitcoin comporte des risques importants, dont une forte volatilité et la perte possible du capital investi. Chaque lecteur reste responsable de ses décisions ; en cas de doute, consultez un professionnel qualifié dans votre juridiction.

Voir aussi

Pour le détail de Taproot et MuSig2 cités dans cet article, voir Taproot, Schnorr et MAST. Pour la seed phrase derrière BIP 32/39/44, voir La seed phrase BIP 39. Pour le multisig opérationnel qui utilise PSBT et MuSig2, voir Multisig Bitcoin. Pour la vue d'ensemble, voir Approfondir Bitcoin.