Matt Corallo a proposé il y a un peu plus d’une semaine un BIP pour la coordination des paiements Bitcoin. Effectuer des paiements Bitcoin a toujours présenté un défi en termes de coordination, à la fois en chaîne et hors chaîne avec des protocoles comme Lightning, pour différentes raisons. Lorsqu’il s’agit de systèmes numériques comme le courrier électronique ou de systèmes de paiement comme Paypal, Cashapp, etc., les gens sont très habitués au concept d’identifiant statique unique. Si vous souhaitez envoyer un e-mail à John, envoyez simplement un e-mail à « john@(insérer le domaine) ». Si vous souhaitez envoyer de l’argent à John sur Cashapp, il vous suffit d’envoyer un paiement à @John sur Cashapp.
Il s’agit de l’expérience utilisateur que les gens connaissent, et lorsqu’il s’agit de comportements et d’attentes bien ancrés des utilisateurs, il est incroyablement difficile de les pousser à un changement substantiel ou brutal de leur comportement. Si vous leur présentez un outil qui nécessite cela, cela présente un degré élevé de friction et va très probablement dissuader la plupart des gens d’utiliser cet outil.
Les paiements en chaîne rencontrent un problème avec cette attente, non pas en raison de l’incapacité d’avoir un identifiant statique (une adresse unique), mais en raison des implications en matière de confidentialité de la publication d’une seule adresse en chaîne et du fait que toutes les personnes avec lesquelles vous interagissez l’utilisent. pour vous payer. Il met l’intégralité de votre historique de paiement et de votre propriété de pièces à la vue de tous. Si vous ne recevez que rarement de l’argent de temps en temps, par exemple lorsque vous êtes payé pour un travail ou que vous réglez des comptes de bar avec des gens, ce n’est pas du tout un fardeau d’ouvrir simplement votre portefeuille et de générer une nouvelle adresse à laquelle recevoir. Cependant, si vous recevez fréquemment de l’argent, en particulier dans les cas où vous ne sollicitez pas directement le paiement, cela représente un lourd fardeau.
C’est pourquoi des outils tels que BTCPay Server ont été créés, afin de réduire les barrières à l’entrée pour que les gens puissent mettre en place l’infrastructure nécessaire pour automatiser la réception de fonds sans faire quelque chose de naïf comme publier une adresse unique pour tous ceux qui vous paient pour la réutilisation. Cependant, cela nécessite d’exécuter un serveur constamment disponible en ligne. Bien que le projet ait considérablement abaissé la barre de compréhension requise, il reste un fardeau élevé pour un utilisateur qui souhaite simplement pouvoir recevoir passivement de l’argent.
La même chose est vraie pour Lightning, mais en pire. Une facture n’est valable que pour un seul paiement. Contrairement à une adresse en chaîne, qui peut être réutilisée même si c’est une horrible pratique, une facture Lightning ne peut pas être utilisée. Une fois la facture payée ou expirée, le nœud Lightning en question refusera toute tentative de paiement. Cette dynamique a conduit à la création de la spécification LNURL, ainsi que des adresses Lightning construites sur celle-ci. LNURL est un protocole de connexion à un serveur HTTP via une adresse IP statique qui peut être partagée une fois afin d’obtenir une véritable facture Lightning à payer depuis le serveur. En plus de cela, les adresses Lightning sont un schéma de dénomination au-dessus de LNURL structuré de la même manière que les adresses e-mail: John@(domaine du serveur LNURL).
Toutes ces solutions ont des inconvénients. L’obligation d’exécuter un logiciel supplémentaire (un serveur HTTP) qui reste en ligne tout le temps en plus de votre portefeuille Bitcoin ou de votre nœud Lightning; faire une demande au serveur BTCPay/LNURL divulgue l’adresse IP de l’expéditeur au destinataire; en s’appuyant sur les autorités de certification TLS.
Utilisez simplement le DNS
Les outils de serveur HTTP tels que LNURL, lorsqu’ils sont associés à Lightning Address, utilisent des domaines pour résoudre la connexion au serveur HTTP. De même, les serveurs BTCPay sont tous configurés avec des domaines plutôt qu’en utilisant des adresses IP brutes. L’idée de Matt est la suivante : pourquoi ne pas simplement supprimer la dépendance à l’égard de HTTP et utiliser le système de noms de domaine lui-même?
DNS vous permet d’associer des enregistrements TXT à un nom de domaine donné, créant ainsi de petit* enregistrements lisibles par l’homme (ou la machine) qui peuvent être interrogés à partir des serveurs DNS. En combinaison avec les extensions de sécurité du système de noms de domaine (DNSSEC), les enregistrements DNS TXT fournissent un mécanisme qui peut être utilisé pour interroger des informations de paiement sans les frais généraux et la charge liés à l’exécution d’un serveur HTTP, et offrent également un peu plus de flexibilité et d’ouverture. DNSSEC fournit un certain nombre d’outils pour signer cryptographiquement les entrées DNS, y compris les enregistrements TXT, avec les clés DNS inhérentes à la structure hiérarchique du DNS. Cela garantit que l’enregistrement TXT que vous interrogez est l’enregistrement signé et distribué aux serveurs DNS de niveau inférieur à partir du serveur/clé racine local.
Cela présente le véritable avantage du DNS en tant que moyen de récupération des données de paiement : dites adieu à l’obligation d’exécuter un serveur HTTP. Un enregistrement TXT peut coder une adresse Bitcoin en chaîne (bien que le BIP recommande spécifiquement de NE PAS le faire si vous n’êtes pas en mesure de faire régulièrement tourner de nouvelles adresses pour empêcher la réutilisation des adresses), mais plus important encore, il peut également contenir une offre Lightning BOLT 12.
Ces enregistrements peuvent être récupérés à partir de n’importe quel serveur DNS, de votre propre serveur local, de votre FAI, voire d’un serveur public comme Google ou Cloudflare. À partir de ce point fondamental, une lacune des solutions basées sur HTTP est résolue; vous ne divulguez plus votre adresse IP à la personne que vous essayez de payer. Désormais, dans le cas de l’utilisation du DNS de votre FAI ou d’un serveur public comme Google ou Cloudflare sans VPN ou Tor, vous leur révélez votre adresse IP; le BIP encourage clairement la prise en charge de la résolution DNS sur un VPN ou Tor spécifiquement pour cette raison.
La combinaison de cette proposition avec BOLT 12 supprime le besoin d’exécuter un logiciel auxiliaire qui présente un problème de sécurité très réel pour les utilisateurs non avertis, et permet à la propriété d’un domaine seul de donner aux utilisateurs tout ce dont ils ont besoin pour disposer d’un mécanisme permettant de localiser les informations de paiement avec un simple contact humain. identifiant lisible. BOLT 12 ne nécessite aucun serveur HTTP, gérant la livraison réelle des factures via des connexions acheminées en oignon directement via le réseau Lightning, et prend en charge les offres, un identifiant statique qui peut être utilisé pour trouver une route en oignon vers ce nœud Lightning. Le problème est que l’offre est codée sous la forme d’une chaîne massive et aléatoire, comme une facture elle-même, ce qui en fait un horrible identifiant lisible/utilisable par l’homme, sauf via l’utilisation de codes QR ou le copier-coller.
En stockant une offre dans un enregistrement DNS TXT, tout ce dont un utilisateur a besoin pour effectuer un paiement est le domaine de quelqu’un à saisir dans son portefeuille afin qu’il puisse récupérer l’enregistrement TXT, récupérer l’offre BOLT 12, puis effectuer le paiement. Ils n’ont pas besoin d’héberger de serveur ni d’exécuter de logiciel autre que leur nœud Lightning, le système DNS gère tout pour eux jusqu’à l’hébergement de leur BOLT 12 Offer quelqu’un que les utilisateurs souhaitant les payer peuvent trouver.
Est-ce un système parfaitement fiable? Non. Est-ce bien meilleur que les systèmes basés sur HTTP? Absolument. Le problème avec des problèmes comme celui-ci est qu’il existe une certaine attente en matière d’UX et de comportement que la plupart des gens ont en ce qui concerne les systèmes numériques sont censés fonctionner dans leur esprit. Sans reproduire cette UX, de grands groupes de personnes utiliseront simplement des alternatives qui répondent à ces attentes UX. Compte tenu de cette réalité, en essayant d’intégrer Bitcoin dans le cadre de ces attentes UX, l’objectif de conception devrait être de répondre aux besoins des utilisateurs avec le minimum de confiance injectée, le minimum de charge imposée aux utilisateurs et le potentiel minimal de perte de vie privée de nouvelles manières. Je pense que le BIP de Matt coche toutes ces cases par rapport aux solutions existantes.
