Le bulletin de cette semaine résume une mise à jour de la spécification des annonces de liquidité. Sont également incluses nos rubriques habituelles avec des questions et réponses populaires de la communauté Bitcoin Stack Exchange, des annonces de nouvelles versions et versions candidates, ainsi que les changements apportés aux principaux logiciels d’infrastructure Bitcoin.

Nouvelles

• ● Mise à jour de la spécification des annonces de liquidité : Lisa Neigut a publié sur la liste de diffusion Lightning-Dev pour annoncer une mise à jour de la spécification des annonces de liquidité. Cette fonctionnalité, implémentée dans Core Lightning et actuellement en cours de développement pour Eclair, permet à un nœud d’annoncer qu’il est prêt à contribuer des fonds à un canal à financement double. Si un autre nœud accepte l’offre en demandant l’ouverture d’un canal, le nœud demandeur doit payer au nœud offrant des frais initiaux. Cela permet à un nœud ayant besoin de liquidité entrante (par exemple, un commerçant) de trouver des pairs bien connectés pouvant fournir cette liquidité à un taux du marché, en utilisant uniquement des logiciels open source et le protocole de diffusion décentralisé LN.

  Les mises à jour comprennent quelques changements structurels ainsi qu’une plus grande flexibilité de la durée du contrat et du plafond des frais de transfert. Le message a reçu plusieurs réponses sur la liste de diffusion et d’autres modifications de la spécification sont attendues. Le message de Neigut note également que la construction actuelle des annonces de liquidité et des annonces de canal rend théoriquement possible de prouver cryptographiquement, le cas échéant, une violation du contrat par une des deux parties. Il reste à résoudre le problème de la conception d’une preuve de fraude compacte pouvant être utilisée dans un contrat de caution pour inciter au respect du contrat.

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

Bitcoin Stack Exchange est l’un des premiers endroits où les contributeurs d’Optech cherchent des réponses à leurs questions, ou lorsque nous avons quelques moments libres pour aider les utilisateurs curieux ou confus. Dans cette rubrique mensuelle, nous mettons en évidence certaines des questions et réponses les plus votées publiées depuis notre dernière mise à jour.

• ● Le schéma de signature numérique Schnorr est-il un schéma interactif de multisignature sans être un schéma non interactif agrégé ? Pieter Wuille décrit les différences entre les multisignatures, l’agrégation de signatures, l’agrégation de clés et le multisig Bitcoin, et mentionne plusieurs schémas connexes, notamment BIP340, les signqtures de Schnorr, MuSig2, FROST et Bellare-Neven 2006.

• ● Est-il conseillé d’utiliser un nœud complet tourant sur une version candidate sur le réseau principal ? Vojtěch Strnad et Murch soulignent que l’exécution de versions candidates de Bitcoin Core sur le réseau principal ne pose que peu de risques pour le réseau Bitcoin, mais les utilisateurs des API, du portefeuille ou d’autres fonctionnalités de Bitcoin Core doivent faire preuve de prudence et effectuer des tests appropriés pour leur configuration.

• ● Quelle est la relation entre nLockTime et nSequence? Antoine Poinsot et Pieter Wuille répondent à une série de questions de Stack Exchange sur nLockTime et nSequence, y compris la relation entre les deux, le but initial de nLockTime, les valeurs potentielles de nSequence et la relation avec BIP68 et OP_CHECKLOCKTIMEVERIFY.

• ● Que se passerait-il si nous fournissons à OP_CHECKMULTISIG plus de signatures que le nombre seuil (m) ? Pieter Wuille explique que bien que cela était possible auparavant, le BIP147 soft fork de malléabilité des éléments de pile factices n’autorise plus la présence d’un élément de pile supplémentaire dans OP_CHECKMULTISIG et OP_CHECKMULTISIGVERIFY avec une valeur arbitraire.

• ● Qu’est-ce que la “politique” (mempool) ? Antoine Poinsot définit les termes “politique” et “standardness” dans le contexte de Bitcoin Core et donne quelques exemples. Il renvoie également à la série de Bitcoin Optech sur la série en attente de confirmation sur cette politique.

• ● Que signifie Pay to Contract (P2C) ? Vojtěch Strnad décrit Pay-to-Contract (P2C) et renvoie à la proposition originale.

• ● Une transaction non-segwit peut-elle être sérialisée dans le format segwit ? Pieter Wuille souligne que bien que plusieurs anciennes versions de Bitcoin Core permettaient involontairement le format de sérialisation étendu pour les transactions non-segwit, BIP144 spécifie que les transactions non-segwit doivent utiliser l’ancien format de sérialisation.

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.

• ● Core Lightning 23.11 est une version de la prochaine version majeure de cette implémentation de nœud LN. Elle offre une flexibilité supplémentaire au mécanisme d’authentification rune, une vérification de sauvegarde améliorée, de nouvelles fonctionnalités pour les plugins.

• ● Bitcoin Core 26.0rc3 est un candidat à la prochaine version majeure de l’implémentation de nœud complet prédominante. Un guide de test est disponible.

Modifications de code et de documentation notables

Modifications notables cette semaine dans Bitcoin Core, Core Lightning, Eclair, LDK,LND, libsecp256k1, Interface de portefeuille matériel (HWI), Rust Bitcoin, Serveur BTCPay, BDK, Bitcoin Improvement Proposals (BIPs), Lightning BOLTs, et Bitcoin Inquisition.

• ● Rust Bitcoin #2213 modifie la prédiction du poids pour les entrées P2WPKH lors du processus de l’estimation des frais. Depuis les versions 0.10.3 et 0.11.1 de Bitcoin Core, les transactions avec des signatures de grande taille sont considérées comme non standard. Par conséquent, les processus de construction de transactions peuvent supposer en toute sécurité que les signatures ECDSA sérialisées prendront au maximum 72 octets au lieu de la limite supérieure précédemment utilisée de 73 octets.

• ● BDK #1190 ajoute une nouvelle méthode Wallet::list_output qui récupère tous les outputs dans le portefeuille, à la fois les outputs dépensés et les outputs non dépensés. Auparavant, il était facile d’obtenir une liste d’outputs non dépensés mais difficile d’obtenir une liste d’outputs dépensés.