Le bulletin de cette semaine contient des liens vers une ébauche de BIP pour une proposition d’opcode OP_VAULT, résume une discussion sur la possibilité d’autoriser les nœuds LN à définir un indicateur de qualité de service sur leurs canaux, relaie une demande de commentaires sur les critères d’évaluation des nœuds voisins LN, et décrit une ébauche de BIP pour un schéma de sauvegarde et de récupération des graines qui peut être exécuté de manière fiable sans électronique. Vous trouverez également nos sections habituelles avec des résumés des questions et réponses les plus importantes du Bitcoin StackExchange, des annonces de nouvelles versions et de versions candidates, et descriptions de principaux changements apportés aux logiciels d’infrastructure Bitcoin les plus répandus.

Nouvelles

  • ● Projet de BIP pour OP_VAULT : James O’Beirne a posté sur la liste de diffusion Bitcoin-Dev un lien vers un projet de BIP pour l’opcode OP_VAULT qu’il a précédemment proposé (voir Bulletin #234). Il a également annoncé qu’il allait tenter de faire fusionner le code avec Bitcoin Inquisition, un projet visant à tester les changements majeurs proposés aux règles du consensus et du protocole réseau de Bitcoin.

  • ● Indicateur de qualité de service LN : Joost Jager a posté sur la liste de diffusion Lightning-Dev une proposition visant à permettre aux noeuds de signaler qu’un canal est “hautement disponible”, indiquant que son opérateur pense qu’il sera en mesure de transmettre les paiements sans échec. S’il ne parvient pas à transmettre un paiement, l’expéditeur peut choisir de ne pas utiliser ce nœud pour les paiements futurs pendant une très longue période—une durée beaucoup plus longue que celle que l’expéditeur peut utiliser pour les nœuds qui n’ont pas annoncé une haute disponibilité. Les expéditeurs qui maximisent la vitesse de paiement (plutôt que des frais peu élevés) choisiraient de préférence des chemins de paiement constitués de nœuds auto-identifiés comme hautement disponibles.

    Christian Decker a répondu avec un excellent résumé des problèmes des systèmes de réputation, y compris les cas de réputation autoproclamée. L’une de ses préoccupations était que les clients typiques n’enverront pas assez de paiements pour rencontrer fréquemment les mêmes nœuds dans un grand réseau de canaux de paiement. Si les affaires récurrentes sont rares de toute façon, alors la menace de ne pas fournir temporairement des affaires récurrentes peut ne pas être efficace.

    Antoine Riard a rappelé aux participants une approche alternative pour accélérer les paiements : le surpaiement avec récupération. Précédemment décrits comme des paiements boomerang (voir le bulletin n°86) et des trop-perçus remboursables (voir le bulletin n°192), un utilisateur prendrait le montant de son paiement plus un peu d’argent supplémentaire, le diviserait en plusieurs parties, et enverrait les parties par différentes voies. Lorsqu’un nombre suffisant de pièces est arrivé pour payer la facture, le destinataire ne réclame que ces pièces et rejette toutes les pièces supplémentaires (avec des fonds supplémentaires) qui arrivent plus tard. Cela exige que les expéditeurs qui veulent des paiements rapides aient des fonds supplémentaires dans leur canal, mais cela fonctionne même si certains des chemins choisis par l’expéditeur échouent. Cela réduit la nécessité pour les utilisateurs d’être en mesure de trouver facilement des canaux hautement disponibles. Le défi de cette approche est de construire un mécanisme qui empêche les récepteurs de garder tout paiement excédentaire qui arrive.

  • ● Feedback demandé sur la notation de bon voisinage des LN : Carla Kirk-Cohen et Clara Shikhelman ont posté sur la liste de diffusion Lightning-Dev afin de solliciter des commentaires sur les paramètres recommandés pour déterminer comment un nœud devrait juger si ses contreparties de canal sont une bonne source de paiements transférés. Elles suggèrent plusieurs critères pour juger et recommandent des paramètres par défaut pour chaque critère, mais cherchent à obtenir des commentaires sur les choix effectués.

    Si un nœud détermine que l’un de ses pairs est un bon voisin et que ce voisin marque un paiement transmis comme étant endossé par lui, le nœud peut donner à ce paiement l’accès à davantage de ses ressources que ce qu’il donne aux paiements non qualifiés. Le nœud peut également approuver le paiement lorsqu’il le transmet au canal suivant. Comme décrit dans un article antérieur co-écrit par Shikhelman (voir bulletin #226), ceci fait partie d’une proposition visant à atténuer les attaques par brouillage de canal.

  • ● Proposition de BIP pour le système d’encodage des semences Codex32 : Russell O’Connor et Andrew Poelstra (utilisant des anagrammes de leurs noms) ont proposé un BIP pour un nouveau schéma de sauvegarde et de restauration de graines BIP32. Similaire à SLIP39, il permet optionnellement de créer plusieurs parts en utilisant le Shamir’s Secret Sharing Scheme (SSSS), nécessitant qu’un nombre configurable de parts soient utilisées ensemble pour récupérer la graine. Un attaquant qui obtient moins que le nombre seuil de parts n’apprendra rien sur la graine. Contrairement aux codes de récupération BIP39, Electrum, Aezeed et SLIP39 qui utilisent une liste de mots, Codex32 utilise le même alphabet que les adresses bech32. Un exemple de part de l’ébauche du BIP :

    ms12namea320zyxwvutsrqpnmlkjhgfedcaxrpp870hkkqrm

    Le principal avantage de Codex32 par rapport à tous les systèmes existants est que toutes les opérations peuvent être effectuées en utilisant uniquement un stylo, du papier, des instructions et des découpes de papier. Cela inclut la génération d’une graine codée (le dé peut être utilisé ici), la protection de la graine avec une somme de contrôle, la génération de parts avec somme de contrôle, la vérification des sommes de contrôle et la récupération de la graine. Nous avons trouvé que l’idée de pouvoir vérifier manuellement les sommes de contrôle sur les sauvegardes de graines ou de parts était un concept particulièrement puissant. La seule méthode dont disposent actuellement les utilisateurs pour vérifier la sauvegarde d’une graine individuelle est de l’entrer dans un dispositif informatique de confiance et de voir s’il obtient les clés publiques attendues—mais déterminer si un dispositif est de confiance n’est souvent pas une procédure triviale. Pire encore, pour vérifier l’intégrité des partages SSSS existants (par exemple, dans SLIP39), l’utilisateur doit réunir chaque partage qu’il souhaite vérifier avec suffisamment d’autres partages pour atteindre le seuil, puis les entrer dans un dispositif informatique de confiance. Cela signifie que la vérification de l’intégrité des partages annule l’un des principaux avantages des partages, à savoir la possibilité de préserver la sécurité des informations en les répartissant entre plusieurs endroits ou personnes. Avec Codex32, les utilisateurs peuvent vérifier régulièrement l’intégrité de chaque partage individuellement en utilisant simplement du papier, un stylo, quelques documents imprimés et quelques minutes de temps.

    La discussion sur la liste de diffusion a principalement porté sur les différences entre Codex32 et SLIP39, qui est utilisé en production depuis quelques années maintenant. Nous recommandons à toute personne intéressée par Codex32 de consulter son site Web ou de regarder la vidéo de l’un de ses auteurs. Avec le projet de BIP, les auteurs espèrent que les portefeuilles commenceront à prendre en charge l’utilisation de graines codées en Codex32.

Questions et réponses sélectionnées dans Bitcoin Stack Exchange

Bitcoin Stack Exchange est l’un des premiers endroits où les collaborateurs d’Optech cherchent des réponses à leurs questions—ou, lorsque nous avons quelques moments libres, nous aidons les utilisateurs curieux ou égarés. Dans cette rubrique mensuelle, nous mettons en lumière certaines des questions et réponses les plus plébicités depuis notre dernière mise à jour.

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.

  • ● BDK 0.27.1 est une mise à jour de sécurité visant à corriger une vulnérabilité qui “permet parfois […] un débordement des limites d’un tableau lors de la saisie de grandes chaînes dans la fonction printf de SQLite”. Seuls les logiciels utilisant la fonction optionnelle de base de données SQLite de BDK doivent être mis à jour. Voir le rapport de vulnérabilité pour plus de détails.

  • ● Core Lightning 23.02rc3 est une version candidate pour une nouvelle version de maintenance de cette implémentation populaire de LN.

Changements principaux dans le code et la documentation

Changements notables cette semaine dans Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), et Lightning BOLTs.

  • ● Bitcoin Core #24149 ajoute la prise en charge de la signature pour les miniscript basés sur les sorties de descripteurs de P2WSH. Bitcoin Core sera en mesure de signer tout descripteur miniscript en entrée si toutes les images préalables et les clés nécessaires sont disponibles et si les délais sont respectés. Certaines fonctionnalités manquent encore pour une prise en charge complète des miniscripts dans le portefeuille Bitcoin Core : le portefeuille ne peut pas encore estimer le poids de l’entrée pour certains descripteurs avant la signature et ne peut pas encore signer les PSBT dans certains cas marginaux. La prise en charge de Miniscript pour les sorties P2TR est également toujours en attente.

  • ● Bitcoin Core #25344 met à jour les RPC bumpfee et psbtbumpfee pour créer des hausses de frais Replace By Fee (RBF). La mise à jour permet de spécifier des sorties pour la transaction de remplacement. Le remplacement peut contenir un ensemble de sorties différent de celui de la transaction remplacée. Ceci peut être utilisé pour ajouter de nouvelles sorties (par exemple, pour le traitement par lots des paiements itératif) ou pour supprimer des sorties (par exemple, pour tenter d’annuler un paiement non confirmé).

  • ● Eclair #2596 limite le nombre de fois qu’un pair tentant d’ouvrir un canal doublement financéle canal peut faire sauter la transaction d’ouverture du canal par RBF avant que le noeud n’accepte plus aucune tentative de mise à jour. Ceci est motivé par le fait que le nœud a besoin de stocker des données sur toutes les versions possibles de la transaction d’ouverture de canal, donc permettre des sauts de frais illimités pourrait être un problème. Normalement, le nombre de dépassements de frais qui peuvent être créés est limité en pratique par la nécessité pour chaque remplacement de payer des frais de transaction supplémentaires. Toutefois, le protocole de double financement prévoit qu’un nœud stocke même les transactions à frais réduits qu’il ne peut pas valider entièrement, ce qui signifie qu’un attaquant pourrait créer un nombre illimité de transactions à frais réduits invalides qui ne seront jamais confirmées et ne lui coûteront jamais de frais de transaction.

  • ● Eclair #2595 continue le travail du projet sur l’ajout du support pour le jointage, dans ce cas avec des mises à jour des fonctions utilisées pour construire les transactions.

  • ● Eclair #2479 ajoute la prise en charge du paiement des offres dans le flux suivant : un utilisateur reçoit une offre, demande à Eclair destinataire, vérifie que la facture contient les paramètres attendus, et paie la facture.

  • ● LND #5988 ajoute un nouvel estimateur de probabilité optionnel pour trouver des chemins de paiement. Il est en partie basé sur des recherches antérieures sur la recherche de chemins (voir le Bulletin #192) avec des apports supplémentaires provenant d’autres approches.

  • ● Rust Bitcoin #1636 ajoute une fonction predict_weight(). L’entrée de la fonction est un modèle pour la transaction à construire ; la sortie est le poids attendu de la transaction. Ceci est particulièrement utile pour la gestion des frais : pour déterminer quelles entrées doivent être ajoutées à une transaction, le montant des frais doit être connu, mais pour déterminer le montant des frais, la taille de la transaction doit être connue. La fonction peut fournir une estimation raisonnable de la taille sans avoir à construire une transaction candidate.