Le bulletin de cette semaine résume une proposition visant à améliorer les surpaiements redondants sur LN et renvoie à une discussion sur les attaques de partitionnement potentielles contre les nœuds complets. Sont également incluses nos sections régulières résumant les changements récents apportés aux clients et services, les annonces de nouvelles versions et de candidats à la publication, et les résumés des modifications notables apportées aux logiciels d’infrastructure Bitcoin populaires.

Nouvelles

  • ● Surpaiements redondants financés par LSP : le développeur ZmnSCPxj a posté sur Delving Bitcoin une proposition permettant aux LSP (Lightning Service Providers) de fournir le financement (liquidité) supplémentaire requis pour les surpaiements redondants. Dans les propositions originales pour les surpaiements redondants, Alice paie Zed en envoyant plusieurs paiements par plusieurs itinéraires de manière à ce que seul Zed puisse réclamer l’un des paiements ; le reste des paiements est remboursé à Alice. L’avantage de cette approche est que les premières tentatives de paiement pour atteindre Zed peuvent réussir tandis que d’autres tentatives sont encore en cours dans le réseau, augmentant la vitesse des paiements sur LN.

    Les inconvénients de cette approche sont qu’Alice doit avoir un capital supplémentaire (liquidité) pour effectuer les paiements redondants, Alice doit rester en ligne jusqu’à ce que le surpaiement redondant soit complet, et tout paiement qui devient bloqué empêche Alice de pouvoir dépenser cet argent jusqu’à ce que la tentative de paiement expire (jusqu’à deux semaines avec les paramètres couramment utilisés).

    La proposition de ZmnSCPxj permet à Alice de payer uniquement le montant réel du paiement (plus les frais) et ses fournisseurs de services Lightning (LSP) fournissent la liquidité pour envoyer les paiements redondants, offrant l’avantage de vitesse des surpaiements redondants sans exiger qu’elle ait une liquidité supplémentaire, que ce soit brièvement ou jusqu’à l’expiration. Les LSP peuvent également finaliser le paiement alors qu’Alice est hors ligne, donc le paiement peut être complété même si Alice a une mauvaise connectivité.

    Les inconvénients de la nouvelle proposition sont qu’Alice perd une partie de sa vie privée vis-à-vis de ses LSP et que la proposition nécessite plusieurs changements dans le protocole LN en plus du support pour les surpaiements redondants.

  • ● Attaques de partitionnement et d’éclipse utilisant l’interception BGP : le développeur cedarctic a posté sur Delving Bitcoin à propos de l’utilisation des failles dans le protocole Border Gateway Protocol (BGP) pour empêcher les nœuds complets de pouvoir se connecter à des pairs, ce qui peut être utilisé pour partitionner le réseau ou exécuter des attaques d’éclipse. Plusieurs atténuations ont été décrites par cedarctic, avec d’autres développeurs dans la discussion décrivant d’autres atténuations et des moyens de surveiller l’utilisation de l’attaque.

Changements dans les services et logiciels clients

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

  • ● Outil de preuve de réserve à connaissance nulle : Zkpoor génère une preuve de réserves utilisant des preuves STARK sans révéler les adresses ou UTXOs du propriétaire.

  • ● Preuve de concept d’un protocole alternatif de swap sous-marin : Le protocole en preuve de concept Papa Swap atteint la fonctionnalité de swap sous-marin en n’exigeant qu’une transaction au lieu de deux.

Mises à jour et versions candidates

Nouvelles versions et versions candidates pour des projets d’infrastructure Bitcoin populaires. Veuillez envisager de mettre à niveau vers les nouvelles versions ou d’aider à tester les versions candidates.

  • ● Bitcoin Core 30.0rc1 est un candidat à la version pour la prochaine version majeure de ce logiciel de nœud de vérification complète.

  • ● BDK Chain 0.23.2 est une version de cette bibliothèque pour la construction d’applications de portefeuille qui introduit des améliorations dans la gestion des conflits de transactions, redessine l’API FilterIter pour améliorer les capacités de filtrage BIP158, et améliore la gestion des ancres et des réorganisations de blocs.

Changements notables dans le code et la documentation

Changements notables récents dans Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Interface de Portefeuille Matériel (HWI), Rust Bitcoin, BTCPay Server, BDK, Propositions d’Amélioration de Bitcoin (BIPs), Lightning BOLTs, Lightning BLIPs, Inquisition Bitcoin, et BINANAs.

  • ● Bitcoin Core #33268 change la manière dont les transactions sont reconnues comme faisant partie du portefeuille d’un utilisateur en supprimant l’exigence que le montant total des entrées d’une transaction dépasse zéro sats. Tant qu’une transaction dépense au moins une sortie d’un portefeuille, elle sera reconnue comme faisant partie de ce portefeuille. Cela permet aux transactions avec des entrées de valeur nulle, telles que dépenser une ancre éphémère P2A, d’apparaître dans la liste des transactions d’un utilisateur.

  • ● Eclair #3157 met à jour la manière dont il signe et diffuse les transactions d’engagement à distance lors d’une reconnexion. Au lieu de renvoyer l’engagement précédemment signé, il signe à nouveau avec les derniers nonces de channel_reestablish. Les pairs qui n’utilisent pas de nonces déterministes dans les canaux taproot simples auront un nouveau nonce lors de la reconnexion, rendant la signature d’engagement précédente invalide.

  • ● LND #9975 ajoute le support de l’adresse on-chain de secours P2TR aux factures BOLT11, suivant le vecteur de test ajouté dans BOLTs #1276. Les factures BOLT11 ont un champ optionnel f qui permet aux utilisateurs d’inclure une adresse on-chain de secours au cas où un paiement ne pourrait pas être complété sur le LN.

  • ● LND #9677 ajoute les champs ConfirmationsUntilActive et ConfirmationHeight au message de réponse PendingChannel retourné par la commande RPC PendingChannels. Ces champs informent les utilisateurs du nombre de confirmations requises pour l’activation du canal et de la hauteur de bloc à laquelle la transaction de financement a été confirmée.

  • ● LDK #4045 implémente la réception d’un paiement asynchrone par un nœud LSP en acceptant un HTLC entrant au nom d’un destinataire souvent hors ligne, en le retenant, et en le libérant au destinataire plus tard lorsqu’il est signalé. Cette PR introduit une fonctionnalité expérimentale HtlcHold, ajoute un nouveau drapeau hold_htlc sur UpdateAddHtlc, et définit le chemin de libération.

  • ● LDK #4049 implémente la transmission des demandes de facture BOLT12 d’un nœud LSP à un destinataire en ligne, qui répond ensuite avec une nouvelle facture. Si le destinataire est hors ligne, le nœud LSP peut répondre avec une facture de secours, comme permis par l’implémentation de la logique côté serveur pour les paiements asynchrones (voir le Bulletin #363).

  • ● BDK #1582 refactorise les types CheckPoint, LocalChain, ChangeSet, et spk_client pour être génériques et prendre un payload T au lieu d’être fixés aux hashes de blocs. Cela prépare bdk_electrum à stocker les entêtes de blocs complets dans les points de contrôle, ce qui évite les téléchargements répétés d’entêtes et permet les preuves de Merkle mises en cache et le Median Time Past (MTP).

  • ● BDK #2000 ajoute la gestion des réorganisations de blocs à une structure FilterIter refactorisée (voir le Bulletin #339). Plutôt que de diviser son flux à travers plusieurs méthodes, ce PR lie tout à la fonction next(), évitant ainsi les risques de timing. Un point de contrôle est émis à chaque hauteur de bloc pour s’assurer que le bloc n’est pas obsolète et que BDK est sur la chaîne valide. FilterIter scanne tous les blocs et récupère ceux contenant des transactions pertinentes à une liste de script pubkeys, en utilisant les filtres de blocs compacts comme spécifié dans BIP158.

  • ● BDK #2028 ajoute un champ de timestamp last_evicted à la structure TxNode pour indiquer quand une transaction a été exclue du mempool après avoir été remplacée par RBF. Ce PR supprime également la méthode TxGraph::get_last_evicted (Voir le Bulletin #346) car le nouveau champ la remplace.