La newsletter de cette semaine décrit une norme pour la vérification des VTXOs à travers différentes implémentations d’Ark et renvoie à un projet de BIP pour l’expansion de l’espace nonce utilisable par les mineurs dans le champ nVersion de l’en-tête de bloc. Sont également incluses nos sections régulières résumant les récentes discussions sur la modification des règles de consensus de Bitcoin, annonçant des mises à jour et des versions candidates, et décrivant les changements notables dans les projets d’infrastructure Bitcoin populaires.

Nouvelles

• ● Une norme pour la vérification VTXO sans état : Jgmcalpine a posté sur Delving Bitcoin à propos de sa proposition pour V-PACK, une norme de vérification VTXO sans état, qui vise à fournir un mécanisme pour vérifier et visualiser de manière indépendante les VTXOs dans l’écosystème Ark. L’objectif est de développer un vérificateur léger capable de fonctionner sur des environnements embarqués, tels que les portefeuilles matériels, pour permettre l’audit de l’état hors chaîne et maintenir une sauvegarde indépendante des données requises pour une sortie unilatérale.

  En particulier, V-PACK vérifie qu’un chemin de sortie unilatérale existe, en vérifiant que le chemin merkle mène à une ancre valide sur la chaîne et que les préimages de transaction correspondent aux signatures. Cependant, le PDG de Second, Steven Roose, a souligné que l’exclusivité du chemin (c’est-à-dire la vérification que le fournisseur de service Ark (ASP) n’a pas introduit de porte dérobée) n’est pas vérifiée, à quoi Jgmcalpine a répondu que le sujet serait donné à la plus haute priorité dans la feuille de route.

  En raison de différences significatives entre les implémentations d’Ark (spécifiquement, Arkade et Bark), V-PACK propose un schéma Minimal Viable VTXO (MVV) pour permettre la traduction du “dialecte” d’une implémentation vers un format neutre commun, sans que l’environnement embarqué ait besoin d’importer toute la base de code spécifique de l’implémentation.

  L’implémentation de V-PACK, libvpack-rs, est open-source, et un outil en direct pour visualiser les VTXOs est disponible pour les tests.

• ● Projet de BIP pour l’expansion de l’espace nonce nVersion pour les mineurs : Matt Corallo a posté sur la liste de diffusion Bitcoin-Dev un projet de BIP pour augmenter le nombre de bits disponibles dans l’espace nonce de nVersion pour les mineurs de 16 à 24. Cela permettrait plus de candidats de bloc possibles pour le minage uniquement d’en-tête sans avoir à recourir à la rotation de nTime plus souvent qu’une fois par seconde et remplacerait BIP320.

  La motivation pour ce changement est que le BIP320 avait précédemment défini 16 bits de nVersion comme espace nonce supplémentaire, mais il s’avère que les dispositifs de minage ont commencé à utiliser 7 bits de nTime pour un espace nonce supplémentaire. Étant donné l’utilité limitée des bits supplémentaires de nVersion pour l’utilisation dans la signalisation de soft fork, ce projet de BIP suggère d’utiliser certains de ces bits de signalisation pour étendre l’espace nonce supplémentaire de nVersion.

  La raison derrière cela est que fournir un espace nonce supplémentaire pour que les ASICs puissent rouler sans avoir besoin de travail frais du contrôleur peut simplifier la conception des ASIC et il est préférable de le faire dans nVersion au lieu de nTime, qui peut fausser les horodatages des blocs.

Modification du consensus

Une nouvelle section mensuelle résumant les propositions et discussions sur la modification des règles de consensus de Bitcoin.

• ● Extensions aux outils standards pour le support de TEMPLATEHASH-CSFS-IK : Antoine Poinsot a écrit sur la liste de diffusion Bitcoin-Dev à propos de son travail préliminaire pour intégrer la proposition de soft fork taproot-native OP_TEMPLATEHASH dans miniscript et PSBTs.

  Les nouveaux opcodes nécessitent une réévaluation des propriétés de miniscript car ils remettent en question l’hypothèse selon laquelle les signatures et les engagements de transaction sont toujours réalisés ensemble. Ce travail souligne également les limitations de la structure de pile de Script en nécessitant un OP_SWAP avant chaque OP_CHECKSIGFROMSTACK lorsqu’il est utilisé avec miniscript sans autres modifications du système de typage. Étant donné que OP_CHECKSIGFROMSTACK prend 3 arguments, avec soit le message, soit la clé, ou les deux calculés par d’autres fragments de script, il n’y a pas d’ordre d’arguments clairement supérieur qui évite OP_SWAP dans la plupart des cas.

  Les modifications requises pour les PSBTs sont plus simples, principalement un champ par sortie pour mapper les engagements OP_TEMPLATEHASH à leurs transactions complètes pour vérification par les signataires.

• ● Mise à jour Hourglass V2 : Mike Casey a posté une mise à jour sur la liste de diffusion Bitcoin-Dev pour le protocole Hourglass afin de mitiger l’impact sur le marché des attaques quantiques contre certaines pièces perdues. La proposition initiale a été discutée ici. Ce soft fork limiterait la valeur totale de Bitcoin verrouillé par P2PK qui peut être dépensé dans un seul bloc à 1 sortie dépensée et 1 Bitcoin. Ces valeurs spécifiques sont quelque peu arbitraires, mais semblaient pour ceux qui ont répondu représenter un point de Schelling raisonnable pour une telle restriction. Ceux qui ont répondu en faveur du changement se sont concentrés sur les conséquences économiques potentielles d’un grand nombre de Bitcoin vendus par un adversaire quantique. Ceux qui ont répondu contre ont argumenté que la possession de clés secrètes pour déverrouiller certains Bitcoin est la seule manière dont le protocole peut identifier la propriété et que même face à une rupture dans la sécurité cryptographique sous-jacente, le protocole ne devrait pas appliquer de restrictions supplémentaires sur la propriété ou le mouvement des pièces.

• ● Agilité algorithmique pour Bitcoin : Ethan Heilman a écrit sur la liste de diffusion Bitcoin-Dev concernant le besoin potentiel d’RFC7696 Cryptographic Algorithm Agility dans Bitcoin. Heilman propose qu’un algorithme cryptographique soit disponible dans les scripts BIP360 P2MR qui n’est pas destiné à être dépensé actuellement, mais sert plutôt de solution de secours pour faire le pont entre les algorithmes de signature principaux dans l’événement où l’algorithme de signature actuel basé sur secp256k1 (ou un futur algorithme principal) deviendrait non sécurisé. L’idée centrale est que si Bitcoin prend en charge deux algorithmes de signature simultanément, les futures ruptures de l’un ou de l’autre ne doivent pas être aussi critiques que les discussions actuelles autour d’une potentielle rupture quantique de secp256k1.

  D’autres développeurs ont répondu avec des discussions sur divers algorithmes de signature de secours potentiels qui seraient peu susceptibles de se briser dans l’horizon temporel de 75 ans d’Heilman.

  La question de savoir si BIP360 P2MR, ou quelque chose qui semble plus être un P2TR mais opte pour que le keyspend soit désactivé plus tard par un soft fork, ce qui est préférable. Dans P2MR, toutes les dépenses sont des dépenses de script avec soit un mécanisme de signature primaire à coût inférieur, soit un mécanisme de secours à coût supérieur choisi parmi les feuilles de merkle. Dans une variante P2TR, le type de signature primaire est un key spend à coût inférieur jusqu’à ce qu’il soit désactivé en raison d’une faille cryptographique et seul le mécanisme de secours doit être une feuille de merkle. Heilman a suggéré que les utilisateurs de stockage à froid préféreraient P2MR et que les portefeuilles chauds pourraient facilement passer à un nouveau type de sortie si nécessaire, rendant l’algorithme de signature de secours avec script inutile pour les deux principaux types d’utilisateurs.

• ● Les limitations de l’agilité cryptographique dans Bitcoin : Pieter Wuille a écrit à la liste de diffusion Bitcoin-Dev sur les limitations de l’agilité cryptographique mentionnée dans l’élément précédent. Spécifiquement, parce que Bitcoin, comme tout argent, est basé sur la croyance, si la propriété de Bitcoin est sécurisée par plusieurs systèmes cryptographiques, les partisans de chaque schéma veulent que leur schéma soit utilisé universellement et, important, ne veulent pas que d’autres schémas soient utilisés car ils affaibliraient l’invariant fondamental de la sécurité de la propriété. Wuille suppose qu’avec le temps, les anciens schémas de signature devront être désactivés dans le cadre de la migration d’un schéma à un autre.

  Heilman propose que, parce que le schéma de signature secondaire proposé pour l’agilité algorithmique est beaucoup plus coûteux que le schéma actuel (et, espérons-le, un futur schéma primaire), il resterait une sauvegarde et seulement utilisé pour les migrations lorsque le schéma primaire a été démontré comme étant suffisamment affaibli, évitant ainsi la nécessité de désactiver le schéma secondaire après chaque migration vers un nouveau schéma primaire.

  John Light prend le point de vue opposé à celui de Wuille, affirmant que désactiver les anciens schémas de signature, même non sécurisés, est une menace plus grande pour la croyance partagée dans le modèle de propriété de Bitcoin que les pièces encore sécurisées par de tels schémas non sécurisés étant revendiquées par celui qui les brise. Affirmant essentiellement que l’aspect le plus important du modèle de propriété de Bitcoin est l’indélébilité de la validité de chaque script de verrouillage du moment où il est créé jusqu’à ce qu’il soit dépensé.

  Conduition réfute les préconditions de Wuille en démontrant que (grâce à la flexibilité de Script) les utilisateurs peuvent exiger des signatures de plusieurs schémas de signature pour débloquer leurs pièces. Cela permet aux utilisateurs d’exprimer un ensemble plus large d’hypothèses de sécurité que celles qui ont donné lieu à la conclusion de Wuille selon laquelle les schémas non sécurisés devraient être désactivés et que les utilisateurs de chaque schéma voudraient presque que personne n’utilise les autres.

  La discussion se poursuit avec quelques clarifications mais sans conclusions fermes quant à la manière dont Bitcoin peut pratiquement migrer d’un cryptosystème à un autre, que ce soit en réponse à un adversaire quantique ou pour toute autre raison.

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 28.4rc1 est un candidat à la sortie pour une version de maintenance d’une série de versions majeures précédentes. Il contient principalement des corrections de migration de portefeuille et la suppression d’un DNS seed peu fiable.

Changements notables dans le code et la documentation

Changements notables récents dans Bitcoin Core, Core Lightning, Eclair, LDK,LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), Lightning BOLTs, Lightning BLIPs, Bitcoin Inquisition, et BINANAs.

• ● Bitcoin Core #33616 ignore la vérification de dépense de poussière éphémère (CheckEphemeralSpends) pendant les réorganisations de blocs lorsque les transactions confirmées réintègrent le pool de mémoire. Auparavant, ces transactions étaient rejetées par la politique de relais car elles sont ramenées individuellement plutôt qu’en tant que paquet. Cela suit le même modèle que Bitcoin Core #33504 (voir le Bulletin #375), qui ignorait les vérifications de topologie TRUC pendant les réorganisations pour la même raison.

• ● Bitcoin Core #34616 introduit un modèle de coût plus précis pour l’algorithme de linéarisation en forêt couvrante (SFL), en utilisant des limites de coût pour limiter la quantité de temps CPU dépensé à chercher une linéarisation optimale de chaque cluster. Le modèle précédent ne suivait qu’un type d’opération interne, résultant en une faible corrélation entre le coût rapporté et le temps CPU réellement dépensé. Le nouveau modèle suit de nombreuses opérations internes avec des poids calibrés à partir de benchmarks sur divers matériels, fournissant une approximation bien plus proche du temps réel.

• ● Eclair #3256 ajoute un nouvel événement ChannelFundingCreated émis lorsqu’une transaction de financement ou d’épissure a été signée et est prête à être publiée. Cela est particulièrement utile pour les canaux financés par une seule partie où le côté non financeur n’a pas l’opportunité de valider les entrées au préalable et peut vouloir fermer de force avant que le canal ne soit confirmé.

• ● Eclair #3258 ajoute un trait ValidateInteractiveTxPlugin qui permet aux plugins d’inspecter et de rejeter les entrées et sorties du pair distant dans les transactions interactives avant de signer. Cela s’applique aux ouvertures de canal à double financement et aux épissures, où les deux côtés participent à la construction de la transaction.

• ● Eclair #3255 corrige la sélection automatique du type de canal introduite dans Eclair #3250 (voir le Bulletin #394) de sorte qu’elle n’inclut plus scid_alias pour les canaux publics. Selon les BOLTs, scid_alias est uniquement autorisé pour les canaux privés.

• ● LDK #4402 corrige le minuteur de réclamation HTLC pour utiliser l’expiration CLTV HTLC réelle plutôt que la valeur de la charge utile de l’oignon. Pour les paiements trampoline où un nœud est à la fois un saut trampoline et le destinataire final, l’expiration HTLC réelle est supérieure à ce que l’oignon spécifie, ccar le parcours extérieur du trampoline a ajouté son propre delta CLTV. Utiliser la valeur onion a conduit le nœud à définir une échéance de réclamation plus stricte que nécessaire.

• ● LND #10604 ajoute un backend SQL (SQLite ou Postgres) pour la base de données des paiements sortants de LND, comme alternative à l’actuel magasin de clés-valeurs bbolt. Ce PR de consolidation regroupe plusieurs sous-PRs, notamment #10153 qui a introduit une interface de magasin de paiement abstraite, #9147 qui a implémenté le schéma SQL et le backend principal, et #10485 qui a ajouté une migration de données expérimentale de KV vers SQL. LND a ajouté le support pour PostgreSQL dans le Bulletin #169 et SQLite dans le Bulletin #237.

• ● BIPs #1699 publie BIP442 spécifiant OP_PAIRCOMMIT, un nouveau opcode tapscript qui retire deux éléments de la pile et pousse leur hash SHA256 tagué. Cela fournit une fonctionnalité de multi-engagement similaire à ce que OP_CAT permet mais évite d’activer les covenants récursifs. OP_PAIRCOMMIT fait partie de la proposition de soft fork LNHANCE aux côtés de OP_CHECKTEMPLATEVERIFY (BIP119), OP_CHECKSIGFROMSTACK (BIP348), et OP_INTERNALKEY (BIP349). Voir le Bulletin #330 pour la proposition initiale.

• ● BIPs #2106 met à jour BIP352 (paiements silencieux) pour introduire une limite de destinataire par groupe de K_max = 2323, atténuant le temps de scan dans le pire des cas pour des transactions adverses (voir le Bulletin #392). Cette limite plafonne le nombre de sorties qu’un scanner doit vérifier par groupe de destinataires au sein d’une seule transaction. La valeur était initialement proposée à 1000 mais a été augmentée à 2323 pour correspondre au nombre maximum de sorties P2TR qui peuvent tenir dans une transaction de taille standard (100 kvB) et pour éviter l’empreinte des transactions de paiement silencieux.

• ● BIPs #2068 publie BIP128, qui spécifie un format JSON standard pour stocker les plans de récupération de timelock. Un plan de récupération consiste en deux transactions pré-signées pour récupérer les fonds si le propriétaire perd l’accès à son portefeuille : une transaction d’alerte qui consolide les UTXOs du portefeuille vers une seule adresse, et une transaction de récupération qui déplace ces fonds vers des portefeuilles de secours après un timelock relatif de 2 à 388 jours. Si la transaction d’alerte est diffusée prématurément, le propriétaire peut simplement dépenser depuis l’adresse d’alerte pour invalider la récupération.

• ● BOLTs #1301 met à jour la spécification pour recommander un dust_limit_satoshis plus élevé pour les canaux anchor. Avec option_anchors, les transactions HTLC pré-signées n’ont pas de frais, donc leur coût n’est plus pris en compte dans le calcul de la poussière. Ce qui signifie que les sorties HTLC qui passent le contrôle de la poussière peuvent encore être non économiques à réclamer onchain, puisque dépenser celles-ci nécessite une transaction en deuxième étape dont les frais peuvent excéder la valeur de la sortie. La spécification recommande maintenant que les nœuds définissent une limite de poussière qui prend en compte le coût de ces transactions en deuxième étape, et que les nœuds acceptent des valeurs supérieures aux seuils de poussière standard de Bitcoin Core de leurs pairs.