Qu'est-ce qu'un BIP ou Bitcoin Improvement Proposal ?
Bitcoin évolue. Que ce soit au niveau de son protocole ou de son écosystème, Bitcoin n'est pas quelque chose de figé, et il n'est pas le même qu'à sa création en janvier 2009. Néanmoins, cette évolution est complexe et lente, et nécessite un ensemble de méthodes pour avoir lieu convenablement : c'est ici qu'interviennent les BIP ou Bitcoin Improvement Proposals.
Acheter Bitcoin (BTC)
Partenaire Bitpanda
Qu'est-ce qu'un BIP ?
Un BIP, acronyme de l'anglais Bitcoin Improvement Proposal, est une proposition d'amélioration de Bitcoin, qui peut concerner les règles de consensus, la communication pair-à-pair, l'interface logicielle, les applications ou tout autre chose relative à Bitcoin. Il s'agit généralement d'un court document technique décrivant la modification à effectuer, qui est ensuite utilisé comme standard par l'industrie. L'acronyme BIP est usuellement genré au masculin, bien que le substantif de base (« proposition ») soit féminin.
Puisque Bitcoin est un projet en source ouverte, public, et ne dispose pas d'une autorité centrale, il est essentiel que les différents acteurs communiquent de manière efficace et c'est en cela que le système des BIP est important. Le fonctionnement de Bitcoin, son développement et sa gouvernance reposent ainsi en partie sur ce système.
Le système des BIP a été formalisé par Amir Taaki le 19 août 2011, peu de temps après le départ définitif de Satoshi Nakamoto. Il s'inspire fortement des Python Enhancement Proposals (PEP) qui servent à améliorer le langage de programmation Python. Initialement défini par le BIP-1, le procédé est aujourd'hui décrit par le BIP-2, rédigé par Luke Dashjr (luke-jr
).
Il existe trois types de BIP :
- Le BIP de suivi de standard (standards track BIP), qui concerne les changements qui affectent la plupart ou toutes les implémentations de Bitcoin, comme une modification du protocole de communication, des règles de validité des blocs ou des transactions, ou encore tout changement ou ajout qui impacte l’interopérabilité des applications utilisant Bitcoin. Il s'agit du type de BIP le plus courant.
- Le BIP informationnel (informational BIP), qui décrit un problème dans la conception de Bitcoin ou donne des directives générales ou des informations à la communauté de Bitcoin, mais ne propose pas de nouvelle fonctionnalité. Le BIP-50 décrivant l'embranchement de mars 2013 est par exemple purement informationnel.
- Le BIP de procédure (process BIP), qui décrit une procédure ou un changement de procédure à adopter. Le BIP de procédure peut concerner le procédé des BIP lui-même (il s'agit alors d'un « méta-BIP »), comme c'est le cas du BIP-1 et du BIP-2.
Notez que ces documents sont utilisés pour Bitcoin (BTC) mais également pour d'autres projets de l'écosystème. Par exemple, les BIP décrivant le fonctionnement des portefeuilles (BIP-32, BIP-39, BIP-44) sont valides pour la grande majorité des cryptomonnaies.
Des procédés équivalents sont construits sur le même modèle pour s'appliquer à d'autres protocoles crypto-économiques : Ethereum dispose ainsi de son propre système d'Ethereum Improvement Proposals (EIP).
Quelles sont les différentes étapes dans la procédure ?
Avant d'être adopté, un BIP doit passer par de nombreuses étapes. À l'instar de l'implémentation de référence (Bitcoin Core), le système des BIP est centralisé mais reste ouvert aux contributions. Ainsi, chacun peut voir sa propre proposition être adoptée, à condition de passer les étapes nécessaires.
Un BIP part d'une idée pouvant se révéler utile à Bitcoin. Même s'il peut être élaboré par plusieurs personnes, il est souvent assigné à un seul auteur qui le soutient publiquement, à des fins d'efficacité. Cet auteur rédige une première version du BIP, en respectant le format défini et en prenant en compte ce qui a été déjà proposé et fait à propos du sujet.
Puis, le BIP est partagé à la communauté des développeurs de Bitcoin, généralement au sein de la liste de diffusion de développement (bitcoin-dev
). Les discussions ont lieu sur cette mailing list.
Enfin, le BIP est officiellement proposé au système sous la forme d'une demande de modification du code (pull request) sur le dépôt GitHub. Pour qu'il soit intégré dans la liste, le BIP doit être approuvé par l'éditeur désigné par Bitcoin Core (Luke Dashjr actuellement).
Les raisons de ne pas intégrer un BIP dans la liste peuvent être nombreuses. Le BIP doit être rédigé dans un format spécifique, ne pas dupliquer une idée existante dans un autre BIP, être trop vague, ne pas être techniquement faisable, . Des raisons plus idéologiques peuvent être invoquées : il peut ainsi être directement rejeté s'il ne respecte pas la rétrocompatibilité des mises à niveau demandée par Bitcoin Core (pas de hard fork) ou s'il n'est pas conforme à la philosophie de Bitcoin (on imagine mal un BIP d'inflation).
Une fois qu'un BIP est jugé acceptable, un numéro lui est assigné et il est intégré au dépôt sous la forme d'une ébauche. Il peut par la suite changer de statut au cours du temps, l'objectif étant qu'il devienne définitif ou actif.
Les différentes statuts d'un BIP sont :
- Ébauche (draft). Une ébauche est une version non finalisée d'un BIP.
- Proposé (proposed). Un BIP peut voir son statut passer d'ébauche (ou de « rejeté ») à « proposé » lorsque son auteur le juge terminé
- Rejeté (rejected). Un BIP peut être « rejeté » s'il n'a pas été amélioré ou corrigé en trois ans, à la demande de n'importe qui. Il peut obtenir le statut d'ébauche ou « proposé » si son auteur fournit les révisions nécessaires.
- Annulé (withdrawn). L'auteur du BIP annule simplement son BIP.
- Reporté (deferred). L'auteur du BIP ou l'éditeur peut choisir de reporter le BIP.
- Définitif (final). Un BIP est considéré comme « définitif » si son adoption a eu lieu dans le monde réel (changement du protocole effectif, intégration dans les applications, etc.)
- Actif (active). Un BIP de procédure passe d'ébauche à « actif » s'il est approuvé par la quasi-totalité de la liste de diffusion (ne s'applique qu'aux BIP de procédure).
- Remplacé (replaced). Un BIP est considéré comme « remplacé » lorsqu'il perd son statut « définitif » ou « actif » au profit d'un autre BIP qui prend sa place.
- Obsolète (obsolete). Un BIP perd son statut « définitif » ou « actif » et devient « obsolète » s'il a perdu sa pertinence de manière vérifiable.
Les BIP importants
La liste de tous les BIP est disponible publiquement. On en dénombre plus d'une centaine. Néanmoins, certains Bip ont une importance plus cruciale que d'autres. En voici une sélection.
Les BIP de procédure
Numéro | Titre | Description | Auteur | Statut |
---|---|---|---|---|
1 | BIP Purpose and Guidelines | Lignes directrices du système des BIP | Amir Taaki | Remplacé |
2 | BIP process, revised | Remplace le BIP-1 à partir de 2016 | Luke Dashjr | Actif |
123 | BIP Classification | Classification des BIP en différentes couches : consensus, réseau, API/RPC, applications. | Eric Lombrozo | Actif |
Méthodes d'activation
Numéro | Titre | Description | Auteur | Statut |
---|---|---|---|---|
9 | Version bits with timeout and delay | Méthode d'activation de soft forks utilisant une fenêtre de signalement des mineurs demandant un seuil de 95 % d'accord. On parle alors de soft fork activé par les mineurs ou MASF. | Pieter Wuille, Peter Todd, Greg Maxwell, Rusty Russell | Définitif |
8 | Version bits with lock-in by height | Variante du BIP-9 basé sur la hauteur de bloc qui force le verrouillage après la fenêtre de signalement. | Shaolin Fry, Luke Dashjr | Ébauche |
135 | Generalized version bits voting | Généralisation du BIP-9 à tous les changements de consensus. | Sancho Panza | Rejeté |
P2SH et alternatives (2012)
Numéro | Titre | Description | Auteur | Statut |
---|---|---|---|---|
12 | OP_EVAL | Code opération pour évaluer un script (ou smart contract) à l'intérieur d'un autre script. | Gavin Andresen | Annulé |
16 | Pay to Script Hash | Schéma standard pour l'utilisation de scripts sur Bitcoin. P2SH a été activé le 1er avril 2012 via le BIP-9. | Gavin Andresen | Définitif |
13 | Address Format for pay-to-script-hash | Format d'adresse pour le schéma Pay to Script Hash (commençant par un 3 ). |
Gavin Andresen | Définitif |
17 | OP_CHECKHASHVERIFY | Compromis entre OP_EVAL et P2SH. | Luke Dashjr | Annulé |
Pour en savoir plus sur le sujet, cet article en anglais résume bien les débats de l'époque : The Battle For P2SH: The Untold Story Of The First Bitcoin War (traduction sur bitcoin.fr)
Gestion des clés dans les portefeuilles (2013 / 2014)
Numéro | Titre | Description | Auteur | Statut |
---|---|---|---|---|
32 | Hierarchical Deterministic Wallets | Dérivation des clés privées et des clés publiques. | Pieter Wuille | Définitif |
39 | Mnemonic code for generating deterministic keys | Phrases mnémotechniques pour représenter l'entropie à partir de laquelle sont générées les clés. | Marek Palatinus, Pavol Rusnak, Aaron Voisine, Sean Bowe | Proposé |
44 | Multi-Account Hierarchy for Deterministic Wallets | Schéma standard de dérivation pour les portefeuilles. | Marek Palatinus, Pavol Rusnak | Proposé |
? Si vous désirez comprendre mieux la dérivation des clés dans les portefeuilles, vous pouvez vous référer à cet article : Portefeuille, phrase secrète et génération d'adresses
Verrous temporels (2015 / 2016)
Numéro | Titre | Description | Auteur | Statut |
---|---|---|---|---|
65 | OP_CHECKLOCKTIMEVERIFY | Verrou à temps absolu dans les scripts. | Peter Todd | Définitif |
68 | Relative lock-time using consensus-enforced sequence numbers | Temps de verrouillage relatif dans les transactions. | Mark Friedenbach, BtcDrak, Nicolas Dorier, kinoshitajona | Définitif |
112 | OP_CHECKSEQUENCEVERIFY | Verrou à temps relatif dans les scripts. | BtcDrak, Mark Friedenbach, Eric Lombrozo | Définitif |
113 | Median time-past as endpoint for lock-time calculations | Définition du temps médian du réseau. | Thomas Kerin, Mark Friedenbach | Défintif |
Pour en savoir plus sur les verrous temporels, il y a mon article sur le sujet : Les temps de verrouillage dans Bitcoin
SegWit (2017)
Numéro | Titre | Description | Auteur | Statut |
---|---|---|---|---|
141 | Segregated Witness (Consensus layer) | Mise à niveau plaçant les scripts de déverrouillage d'une transaction dans un ensemble de données séparé, le témoin. | Eric Lombrozo, Johnson Lau, Pieter Wuille | Définitif |
143 | Transaction Signature Verification for Version 0 Witness Program | Algorithme de signature pour les entrées SegWit. | Johnson Lau, Pieter Wuille | Définitif |
144 | Segregated Witness (Peer Services) | Protocole réseau pour la gestion de SegWit. | Eric Lombrozo, Pieter Wuille | Définitif |
49 | Derivation scheme for P2WPKH-nested-in-P2SH based accounts | Schéma de dérivation pour les adresses P2SH-P2WPKH | Daniel Weigl | Définitif |
84 | Derivation scheme for P2WPKH based accounts | Schéma de dérivation pour les adresses P2WPKH | Pavol Rusnak | Ébauche |
91 | Reduced threshold Segwit MASF | Réduit le seuil d'acceptation du BIP-9 à 80 % pour SegWit. | James Hilliard | Définitif |
148 | Mandatory activation of segwit deployment | Active SegWit le 1er août 2017. SegWit a été verrouillé avant que cet « UASF » soit appliqué. | Shaolin Fry | Définitif |
👉 Pour en savoir plus sur SegWit : Qu'est-ce que SegWit ? Explication technique
Schnorr & Taproot (2021 ?)
Numéro | Titre | Description | Auteur | Statut |
---|---|---|---|---|
340 | Schnorr Signatures for secp256k1 | Algorithme de signature de Schnorr pour la courbe secp256k1 utilisée par Bitcoin. | Pieter Wuille, Jonas Nick, Tim Ruffing | Ébauche |
341 | Taproot: SegWit version 1 spending rules | Mise à niveau permettant d'améliorer la confidentialité et la scalabilité des scripts | Pieter Wuille, Jonas Nick, Anthony Towns | Ébauche |
342 | Validation of Taproot Scripts | Sémantique du langage des scripts mis en place avec Taproot | Pieter Wuille, Jonas Nick, Anthony Towns | Ébauche |
? Pour comprendre ce que sont les signatures de Schnorr et Taproot, voici nos deux articles sur le sujet :