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.

BIP Bitcoin Improvement Proposal processus

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 :

A propos de l'auteur : Ludovic Lars

twitter-soothsayerdatatwitter-soothsayerdata

Je suis fasciné par les cryptomonnaies et par l’impact qu’elles pourraient avoir sur nos vies. De formation scientifique, je m’attache à décrire leur fonctionnement technique de la façon la plus fidèle possible. Sur Cryptoast, je me propose de vous aider à mieux comprendre comment fonctionnent les cryptomonnaies (principalement Bitcoin, Bitcoin Cash et Ethereum) et quels sont les enjeux qui animent cet écosystème fascinant.
Tous les articles de Ludovic Lars.

guest
0 Commentaires
Inline Feedbacks
View all comments