Ce qui suit est un extrait direct de Marty’s Bent Issue #1181 : « BIP21 est une évidence.« Inscrivez-vous à la newsletter ici.

À l’heure actuelle, il existe un énorme obstacle UX pour les utilisateurs de différents fournisseurs de logiciels de portefeuille Bitcoin.

L’une des discussions les plus éclairantes lors de l’événement Bitcoin Takeover qui s’est tenu au Bitcoin Commons ici à Austin vendredi dernier était une table ronde entre Lisa Neigut (c-lightning, Blockstream), Rockstar Dev (Strike, qui utilise lnd) et Miles Suter (Cash App, qui utilise LDK) dirigé par Matt Odell sur les défis de l’interopérabilité entre les différentes implémentations et l’UX globale lors de l’utilisation du Lightning Network. Au cours de la discussion (qui devrait être rendue publique prochainement), le panel a abordé le sujet du BIP21, un BIP que j’ignorais mais dont je suis très excité après l’avoir compris.

À l’heure actuelle, il existe un énorme obstacle UX pour les utilisateurs de différents fournisseurs de logiciels de portefeuille Bitcoin. L’UX autour de l’envoi et de la réception de transactions bitcoin en chaîne et via le Lightning Network. Certains portefeuilles sont uniquement en chaîne, certains ne s’allument que, et certains permettent aux utilisateurs d’utiliser les deux mais vous obligent à basculer manuellement entre les deux lors de l’envoi et de la réception. Entrez BIP21, qui vise à résoudre cet obstacle UX en donnant aux utilisateurs une option lors de l’envoi. BIP21 permettrait aux codes QR qui permettent aux fournisseurs de portefeuilles d’inclure à la fois une facture éclair et une adresse de portefeuille bitcoin en chaîne en un seul endroit.

Ce qu’il faut pour faire avancer BIP21 en tant que norme, c’est que davantage de portefeuilles réseau Lightning commencent à le prendre en charge. À l’heure actuelle, lorsqu’un utilisateur de bitcoins utilisant un portefeuille compatible BIP21 scanne le code QR d’un portefeuille sur lequel BIP21 n’est pas activé, il reçoit un code d’erreur qui peut prêter à confusion et entraîner des frictions UX. Si davantage de portefeuilles réseau Lightning activent BIP21 et permettent aux utilisateurs qui n’envoient que des transactions en chaîne de recevoir une adresse de secours en chaîne, cela mettrait fin à cette friction UX. La meilleure partie est que BIP21 est rétrocompatible, il n’y a donc aucun moyen de priver de ses droits l’homme dans le coma qui se réveille dans une décennie et diffuse une transaction à partir d’un portefeuille qu’il n’a pas touché depuis de nombreuses années.

Au-delà de cela, BIP21 permet aux utilisateurs de prendre une décision consciente quant à savoir s’ils souhaitent envoyer via la couche de protocole ou le réseau Lightning. S’il est mis en œuvre, cela devrait éliminer le besoin de différents onglets d’interface utilisateur sur la chaîne et LN et rendre le processus de transaction beaucoup plus fluide entre les différents portefeuilles.

La première étape vers la réalisation de ces avantages consiste à faire en sorte que chaque portefeuille puisse lire les codes QR BIP21. À partir de là, chaque projet peut commencer à créer des expériences permettant aux utilisateurs de générer des codes de paiement BIP21. Vous devez obtenir un large support pour la numérisation avant qu’il ne soit logique d’obtenir un large support pour générer ces codes de paiement. En espérant que les fournisseurs de portefeuilles en feront une priorité dans un proche avenir.