Le bulletin de cette semaine décrit une proposition visant à permettre la récupération des offres LN en utilisant des adresses DNS spécifiques similaires aux adresses lightning. Nous incluons également nos sections régulières décrivant les mises à jour des clients et des services, les nouvelles versions et les versions candidates, ainsi que les changements apportés aux principaux logiciels d’infrastructure Bitcoin.

Nouvelles

  • ● Adresses LN compatibles avec les offres : Bastien Teinturier a publié un message sur la liste de diffusion Lightning-Dev concernant la création d’adresses de style e-mail pour les utilisateurs LN de manière à tirer parti des fonctionnalités du protocole des offres. Pour contextualiser, il existe une norme populaire d’adresse lightning basée sur LNURL, qui nécessite de faire fonctionner en permanence un serveur HTTP pour associer des adresses de style e-mail à des factures LN. Teinturier note que cela crée plusieurs problèmes :

    • Manque de confidentialité : l’opérateur du serveur peut probablement connaître l’adresse IP de l’émetteur et du destinataire.

    • Risque de vol : l’opérateur du serveur peut effectuer une attaque de type “man-in-the-middle” sur les factures pour voler des fonds.

    • Infrastructure et dépendances : l’opérateur du serveur doit configurer le DNS et l’hébergement HTTPS, et le logiciel de l’émetteur doit pouvoir utiliser le DNS et le HTTPS.

    Teinturier propose trois conceptions basées sur les offres :

    • Lier les domaines aux nœuds : un enregistrement DNS associe un domaine (par exemple, example.com) à un identifiant de nœud LN. L’émetteur envoie un message onion à ce nœud pour demander une offre pour le destinataire final (par exemple, alice@example.com). Le nœud du domaine répond avec une offre signée par sa clé de nœud, permettant à l’émetteur de prouver ultérieurement une fraude s’il a fourni une offre qui ne provenait pas d’Alice. L’émetteur peut maintenant utiliser le protocole des offres pour demander une facture à Alice. L’émetteur peut également associer alice@example.com à l’offre, de sorte qu’il n’ait pas besoin de contacter le nœud du domaine pour les paiements futurs à Alice. Teinturier note que cette conception est extrêmement simple.

    • Certificats dans les annonces de nœuds : le mécanisme existant qu’un nœud LN utilise pour se faire connaître du réseau est modifié pour permettre à une annonce de contenir une chaîne de certificats SSL prouvant que (selon une autorité de certification) le propriétaire de example.com affirme que ce nœud particulier est contrôlé par alice@example.com. Teinturier note que cela nécessiterait que les implémentations LN utilisent une cryptographie compatible avec SSL.

    • Stocker les offres directement dans le DNS : un domaine peut avoir plusieurs enregistrements DNS qui stockent directement des offres pour des adresses particulières. Par exemple, un enregistrement DNS TXT, alice._lnaddress.domain.com, inclut une offre pour Alice. Un autre enregistrement, bob._lnaddress.domain.com, inclut une offre pour Bob. Teinturier note que cela nécessite que le propriétaire du domaine crée un enregistrement DNS par utilisateur (et mette à jour cet enregistrement si l’utilisateur doit modifier son offre par défaut).

    Le message a suscité une discussion active. Une suggestion notable était de permettre éventuellement l’utilisation à la fois de la première et de la troisième suggestion (les suggestions pour lier les domaines aux nœuds et stocker les offres directement dans le DNS).

Modifications apportées aux services et aux logiciels clients

Dans cette rubrique mensuelle, nous mettons en évidence les mises à jour intéressantes des portefeuilles et services Bitcoin.

  • ● Sortie de BitMask Wallet 0.6.3 : BitMask est un portefeuille basé sur le web et une extension de navigateur pour Bitcoin, Lightning, RGB et payjoin.

  • ● Annonce du site de documentation des opcodes : Le site https://opcodeexplained.com/ a récemment été annoncé et fournit des explications sur de nombreux opcodes de Bitcoin. L’effort est en cours et les contributions sont les bienvenues.

  • ● Athena Bitcoin ajoute la prise en charge de Lightning : L’opérateur de distributeur automatique de Bitcoin a récemment annoncé la prise en charge des paiements Lightning pour les retraits en espèces.

  • ● Sortie de Blixt v0.6.9 : La version v0.6.9 inclut la prise en charge de canaux taproot simples, utilise par défaut des adresses de réception bech32m et ajoute une prise en charge supplémentaire des canaux zero conf.

  • ● Annonce du livre blanc Durabit : Le livre blanc Durabit décrit un protocole utilisant des transactions Bitcoin timelocked en conjonction avec une création de monnaie de style chaumien pour inciter à la diffusion de gros fichiers.

  • ● Annonce du livre blanc BitStream : Le livre blanc BitStream présente un prototype préliminaire de protocole pour l’hébergement et l’échange atomique de contenu numérique contre des satoshis en utilisant des verrous temporels et des arbres de Merkle avec vérification et preuves de fraude. Pour une discussion antérieure sur les protocoles de transfert de données payantes, voir Newsletter #53.

  • ● Preuves de concept BitVM : Deux preuves de concept basées sur BitVM ont été publiées, dont une implémente la fonction de hachage BLAKE3 et une autre qui implémente SHA256.

  • ● Bitkit ajoute la prise en charge de l’envoi taproot : Bitkit, un portefeuille Bitcoin et Lightning mobile, a ajouté la prise en charge de l’envoi taproot dans la version v1.0.0-beta.86.

Mises à jour et versions candidates

Nouvelles versions et versions candidates pour les principaux projets d’infrastructure Bitcoin. Veuillez envisager de passer aux nouvelles versions ou d’aider à tester les versions candidates.

Changements notables dans le code et la documentation

Changements notables cette semaine dans Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Interface de portefeuille matériel (HWI), Rust Bitcoin, Serveur BTCPay , BDK, Propositions d’amélioration de Bitcoin (BIPs), Lightning BOLTs, et Bitcoin Inquisition.

  • ● Core Lightning #6857 met à jour les noms de plusieurs options de configuration utilisées pour l’interface REST afin d’éviter les conflits avec le plugin c-lightning-rest.

  • ● Eclair #2752 permet aux données dans une offre de faire référence à un nœud en utilisant soit sa clé publique, soit l’identité de l’un de ses canaux. Une clé publique est le moyen habituel d’identifier un nœud, mais elle utilise 33 octets. Un canal peut être identifié à l’aide d’un BOLT7 short channel identifier (SCID), qui n’utilise que 8 octets. Étant donné que les canaux sont partagés par deux nœuds, un bit supplémentaire est ajouté au SCID pour identifier spécifiquement l’un des deux nœuds. Comme les offres sont souvent utilisées dans des médias à contraintes de taille, les économies d’espace sont toujours intéressantes.