Le bulletin de cette semaine résume plusieurs discussions récentes sur un langage Lisp pour le scripting Bitcoin et comporte 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

  • ● Langage Lisp pour le scripting Bitcoin : Anthony Towns a fait plusieurs publications sur la continuation de son travail concernant la création d’un langage Lisp pour Bitcoin qui pourrait être ajouté à Bitcoin dans un soft fork.

    • ● bll, symbll, bllsh : Towns note qu’il a passé beaucoup de temps à réfléchir aux conseils du développeur de Chia Lisp, Art Yerkes, sur l’assurance d’une bonne correspondance entre le code de haut niveau (ce que les programmeurs écrivent typiquement) et le code de bas niveau (ce qui est réellement exécuté, généralement créé à partir du code de haut niveau par les compilateurs). Il a décidé d’adopter une approche similaire à miniscript où “vous traitez le langage de haut niveau comme une variation conviviale du langage de bas niveau (comme le fait miniscript avec script)”. Le résultat est deux langages et un outil :

      • ● Basic Bitcoin Lisp language (bll) est le langage de bas niveau qui pourrait être ajouté à Bitcoin dans un soft fork. Selon Towns, bll est similaire à BTC Lisp selon sa dernière mise à jour (voir le Bulletin #294).

      • ● Symbolic bll (symbll) est le langage de haut niveau qui est converti en bll. Il devrait être relativement facile pour quiconque déjà familier avec la programmation fonctionnelle.

      • ● Bll shell (bllsh) est un REPL qui permet à un utilisateur de tester des scripts en bll et symbll, de compiler de symbll à bll, et d’exécuter du code avec des capacités de débogage.

    • ● Implémenter des signatures résistantes aux quantiques dans symbll versus GSR : Towns lie à un post Twitter de Jonas Nick sur l’implémentation des signatures Winternitz One Time (WOTS+) en utilisant les opcodes existants et les opcodes spécifiés dans la proposition great script restoration (GSR) de Rusty Russell. Towns compare ensuite l’implémentation de WOTS en utilisant symbll dans bllsh. Cela réduit la quantité de données qui devraient être placées onchain d’au moins 83 % et potentiellement de plus de 95 %. Cela pourrait permettre l’utilisation de signatures résistantes aux quantiques à un coût seulement 30 fois supérieur à celui des sorties P2WPKH.

    • ● Marquages flexibles de pièces : Towns décrit une construction générique compatible avec symbll (et probablement Simplicity) qui permet de partitionner une UTXO en montants spécifiques et conditions de dépense. Si une condition de dépense est remplie, le montant associé peut être dépensé et le reste de la valeur de l’UTXO est retournée à une nouvelle UTXO avec les conditions restantes. Une condition alternative peut également être satisfaite pour permettre de dépenser l’intégralité de l’UTXO ; par exemple, cela pourrait permettre à toutes les parties de convenir de mettre à jour certaines des conditions. C’est un type flexible de mécanisme de covenant, similaire à la proposition précédente de Towns pour OP_TAP_LEAF_UPDATE_VERIFY (TLUV, voir le Bulletin #166), mais Towns a écrit précédemment qu’il pense que covenants n’est “pas un terme précis ou utile”.

      Plusieurs exemples d’utilisation de ces pièces de monnaie flexibles affectées à un usage particulier sont fournis, incluant des améliorations dans la sécurité et l’utilisation des canaux LN (incluant les canaux basés sur LN-Symmetry), une alternative à la version BIP345 de coffre-forts (vaults), et un design de pool de paiements similaire à celui envisagé pour une utilisation avec TLUV mais qui évite les problèmes que cette proposition avait avec les clés publiques x-only.

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 quand nous avons quelques moments libres pour aider les utilisateurs curieux ou perdus. Dans cette rubrique mensuelle, nous mettons en lumière les questions et les réponses qui ont obtenu le plus d’attraction depuis notre dernière mise à jour.

Mises à jour et versions candidates

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

  • ● Core Lightning 24.11rc2 est une version candidate pour la prochaine version majeure de cette implémentation populaire de LN.

  • ● BDK 0.30.0 est une mise-à-jour de cette bibliothèque pour construire des portefeuilles et d’autres applications activées par Bitcoin. Elle inclut plusieurs corrections de bugs mineurs et prépare la mise à niveau anticipée à la version 1.0 de la bibliothèque.

  • ● LND 0.18.4-beta.rc1 est un candidat pour une version mineure de cette implémentation populaire de LN.

Changements notables dans le code et la documentation

Changements récents notables 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, Lightning BLIPs, Inquisition Bitcoin, et BINANAs.

  • ● Bitcoin Core #31122 implémente une interface changeset pour la mempool, permettant à un nœud de calculer l’impact d’un ensemble proposé de changements sur l’état de la mempool. Par exemple, vérifier si les limites d’ancêtre/descendant/TRUC (et les limites de cluster futur) sont violées lorsqu’une transaction ou un paquet est accepté, ou déterminer si une majoration des frais RBF améliore l’état de la mempool. Cette PR fait partie du projet de mempool en cluster.

  • ● Core Lightning #7852 restaure la compatibilité avec les versions antérieures à 24.08 pour le plugin pyln-client (une bibliothèque cliente Python) en réintroduisant un champ de description.

  • ● Core Lightning #7740 améliore le solveur de flux de coût minimum (MCF) du plugin askrene (voir le Bulletin #316) en fournissant une API qui abstrait la complexité de la résolution MCF pour permettre une intégration plus facile des algorithmes de calcul de flux basés sur des graphes récemment ajoutés. Le solveur adopte la même linéarisation de la fonction de coût de canal que renepay(voir le Bulletin #263), ce qui améliore la fiabilité de la recherche de chemin, et introduit le support pour des unités personnalisables au-delà des msats, permettant une plus grande scalabilité pour les paiements importants. Cette PR ajoute les méthodes simple_feasibleflow, get_augmenting_flow, augment_flow, et node_balance pour améliorer l’efficacité des calculs de flux.

  • ● Core Lightning #7719 réalise l’interopérabilité avec Eclair pour le splicing, permettant l’exécution de splices entre les deux implémentations. Cette PR introduit plusieurs changements pour s’aligner sur l’implémentation d’Eclair, y compris le support pour la rotation des clés de financement à distance, l’ajout de batch_size pour les messages signés d’engagement, empêchant la transmission des transactions de financement précédentes en raison des limites de taille de paquet, supprimant les blockhashes des messages, et ajustant les soldes de sortie de financement prédéfinis.

  • ● Eclair #2935 ajoute une notification à l’opérateur du nœud en cas de force close d’un canal initié par un pair du canal.

  • ● LDK #3137 ajoute le support pour l’acceptation de canaux à double financement initiés par des pairs, bien que le financement ou la création de tels canaux ne soit pas encore pris en charge. Si manually_accept_inbound_channels est réglé sur false, les canaux sont automatiquement acceptés, tandis que la fonction ChannelManager::accept_inbound_channel() permet une acceptation manuelle. Un nouveau champ channel_negotiation_type est introduit pour distinguer entre les demandes entrantes pour les canaux à double financement et ceux sans double financement. Les canaux à double financement Zero-conf et la majoration des frais RBF des transactions de financement ne sont pas pris en charge.

  • ● LND #8337 introduit le package protofsm, un cadre réutilisable pour créer des machines à états finis (FSM) protocolaires pilotées par événements dans LND. Au lieu d’écrire du code standard pour gérer les états, les transitions et les événements, les développeurs peuvent définir des états, ce qui déclenche les événements, et les règles pour passer entre eux, et l’interface State encapsulera le comportement, gérera les événements, et déterminera les états terminaux, tandis que les adaptateurs de daemon gèrent les effets secondaires comme la diffusion de transactions et l’envoi de messages aux pairs.