Le bulletin d’information de cette semaine s’intéresse aux recherches autour des preuves de validité à connaissance nulle pour Bitcoin et les protocoles connexes. Vous y trouverez également une nouvelle contribution à notre série hebdomadaire limitée sur la politique du mempool, ainsi que nos sections régulières décrivant les mises à jour des clients et des services, les nouvelles versions et les versions candidates, ainsi que les changements apportés aux principaux projets d’infrastructure de Bitcoin.

Nouvelles

• ● Compression d’états avec preuves de validité à connaissance nulle : Robin Linus a posté sur la liste de diffusion Bitcoin-Dev un article qu’il a co-écrit avec Lukas George sur l’utilisation des preuves de validité pour réduire la quantité d’état qu’un client doit télécharger afin de vérifier sans confiance les opérations futures dans un système. Ils appliquent d’abord leur système à Bitcoin. Ils indiquent qu’ils disposent d’un prototype qui prouve la quantité cumulative de preuves de travail dans une chaîne d’en-têtes de blocs et permet à un client de vérifier qu’un en-tête de bloc particulier fait partie de cette chaîne. Cela permet à un client qui reçoit plusieurs preuves de déterminer laquelle démontre la plus grande preuve de travail.

  Ils disposent également d’un prototype sous-optimal qui prouve que tous les changements d’état des transactions de la chaîne de blocs respectent les règles monétaires (par exemple, le nombre de bitcoins pouvant être créés par un nouveau bloc, le fait que chaque transaction, en dehors des transactions coinbase, ne doit pas créer d’UTXO ayant une valeur supérieure à celle des bitcoins qu’elle détruit (dépense), et qu’un mineur peut réclamer toute différence entre les UTXO détruits dans un bloc et ceux qui ont été créés). Un client recevant cette preuve et une copie de l’ensemble d’UTXO actuel serait en mesure de vérifier que l’ensemble est exact et complet. Ils appellent cela une preuve assumevalid, d’après la fonctionnalité de Bitcoin Core qui permet de ne pas vérifier les scripts des anciens blocs lorsque de nombreux contributeurs s’accordent à dire que leurs nœuds ont tous validé ces blocs avec succès.

  Pour minimiser la complexité de leur preuve, ils utilisent une version de utreexo avec une fonction de hachage optimisée pour leur système. Ils suggèrent séparément que la combinaison de leur preuve avec un client utreexo permettra à ce dernier de commencer à fonctionner comme un nœud complet presque immédiatement après avoir téléchargé une très petite quantité de données.

  En ce qui concerne la facilité d’utilisation de leurs prototypes, ils écrivent que “nous avons mis en œuvre la preuve de la chaîne d’en-tête et la preuve de l’état supposé valide en tant que prototypes. Il est possible de prouver la première, tandis que la seconde nécessite encore des améliorations de performance pour prouver des blocs de taille raisonnable”. Ils travaillent également sur la validation de blocs complets, y compris les scripts, mais affirment qu’ils ont besoin d’une augmentation de la vitesse d’au moins 40 fois pour que cela soit viable.

  Outre la compression de l’état de la chaîne de blocs Bitcoin, ils décrivent également un protocole qui peut être utilisé pour un protocole de jetons à validation côté client similaire à celui utilisé pour les actifs Taproot de Lightning Labs et certaines utilisations de RGB (voir les lettres d’information #195 et #247). Lorsque Alice transfère à Bob une certaine quantité de jetons, Bob doit vérifier l’historique de tous les transferts précédents de ces jetons spécifiques depuis leur création. Dans un scénario idéal, cet historique croît linéairement avec le nombre de transferts. Mais si Bob veut payer à Carole un montant supérieur à celui qu’il a reçu d’Alice, il devra combiner certains des jetons qu’il a reçus d’Alice avec d’autres jetons qu’il a reçus lors d’une autre transaction. Carol devra alors vérifier à la fois l’historique de la transaction avec Alice et l’historique des autres jetons de Bob. C’est ce qu’on appelle une fusion. Si les fusions sont fréquentes, la taille de l’historique qui doit être vérifié approche la taille de l’historique de chaque transfert de ce jeton entre les utilisateurs. En termes comparatifs, dans Bitcoin, chaque nœud complet vérifie chaque transaction effectuée par chaque utilisateur ; dans les protocoles de jetons utilisant la validation côté client, cela n’est pas strictement nécessaire mais finit par le devenir si les fusions sont fréquentes.

  Cela signifie qu’un protocole capable de comprimer l’état de Bitcoin peut également être adapté pour comprimer l’état de l’historique d’un jeton, même si les fusions sont fréquentes. Les auteurs décrivent comment ils y parviendraient. Leur objectif est de produire une preuve que chaque transfert précédent du jeton a suivi les règles du jeton, y compris en utilisant leurs preuves pour Bitcoin afin de prouver que chaque transfert précédent a été ancré dans la chaîne de blocs. Alice pourrait alors transférer les jetons à Bob et lui donner une courte preuve de validité de taille constante ; Bob pourrait vérifier la preuve pour savoir que le transfert a eu lieu à une certaine hauteur de bloc et payer son portefeuille de jetons, ce qui lui donnerait le contrôle exclusif des jetons.

  Bien que le document mentionne fréquemment des recherches et des développements supplémentaires, nous estimons qu’il s’agit d’un progrès encourageant vers une fonctionnalité que les développeurs de Bitcoin souhaitent depuis plus d’une décennie.

En attente de confirmation #2 : Mesures d’incitation

Une série hebdomadaire limitée sur le relais de transaction, l’inclusion dans le mempool et la sélection des transactions minières—y compris pourquoi Bitcoin Core a une politique plus restrictive que celle autorisée par le consensus et comment les portefeuilles peuvent utiliser cette politique de la manière la plus efficace.

L’article de la semaine dernière traitait du mempool comme d’un cache de transactions non confirmées qui fournit une méthode décentralisée permettant aux utilisateurs d’envoyer des transactions aux mineurs. Cependant, les mineurs ne sont pas obligés de confirmer ces transactions ; un bloc contenant uniquement une transaction coinbase est valide selon les règles du consensus. Les utilisateurs peuvent inciter les mineurs à inclure leurs transactions en augmentant la valeur totale d’entrée sans modifier la valeur totale de sortie, ce qui permet aux mineurs de réclamer la différence en tant que frais de transaction.

Bien que les frais de transaction soient courants dans les systèmes financiers traditionnels, les nouveaux utilisateurs de Bitcoin sont souvent surpris de constater que les frais sur la chaîne sont payés non pas en proportion du montant de la transaction, mais en fonction du poids de la transaction. C’est l’espace disponible sur les blocs, et non la liquidité, qui est le facteur limitant. Le taux de change est généralement libellé en satoshis par octet virtuel.

Les règles de consensus limitent l’espace utilisé par les transactions dans chaque bloc. Cette limite permet de maintenir des temps de propagation des blocs faibles par rapport à l’intervalle entre les blocs, ce qui réduit le risque de blocs périmés. Elle permet également de limiter la croissance de la chaîne de blocs et de l’ensemble d’UTXO, qui contribuent directement au coût de démarrage et de maintenance d’un nœud complet.

Ainsi, dans le cadre de leur rôle de cache de transactions non confirmées, les mempools facilitent également une vente aux enchères publique pour l’espace de bloc inélastique : lorsqu’elle fonctionne correctement, la vente aux enchères fonctionne selon les principes du marché libre, c’est-à-dire que la priorité est basée uniquement sur les frais plutôt que sur les relations avec les mineurs.

La maximisation des frais lors de la sélection des transactions pour un bloc (dont le poids total et les opérations de signature sont limités) est un problème NP-hard. Ce problème est encore compliqué par les relations entre les transactions : l’extraction d’une transaction à taux élevé peut nécessiter l’extraction de son parent à taux faible. En d’autres termes, l’extraction d’une transaction à faible taux de falsification peut ouvrir la possibilité d’extraire son enfant à taux de falsification élevé.

Le mempool de Bitcoin Core calcule le taux de frais de chaque entrée et de ses ascendants (appelé ancestor feerate), met en cache ce résultat et utilise un algorithme de construction de modèle de bloc avide. Il trie le mempool dans l’ordre du score d’ancêtre (le minimum du taux de frais de l’ascendant et du taux de frais individuel) et sélectionne les paquets d’ascendants dans cet ordre, en mettant à jour les informations sur les frais et le poids des ascendants des transactions restantes au fur et à mesure. Cet algorithme offre un équilibre entre performance et rentabilité et ne produit pas nécessairement des résultats optimaux. Son efficacité peut être améliorée en limitant la taille des transactions et des paquets ascendants—Bitcoin Core fixe ces limites à 400 000 et 404 000 unités de poids, respectivement.

De même, un descendant score est calculé et utilisé lors de la sélection des paquets à expulser du mempool, car il serait désavantageux d’expulser une transaction à faible taux de frais qui a un descendant à fort taux de frais.

La validation du Mempool fait également appel à des frais et à des tarifs lorsqu’il s’agit de transactions qui dépensent les mêmes intrants, c’est-à-dire des transactions à double dépense ou des transactions conflictuelles. Au lieu de toujours conserver la première transaction qu’ils voient, les nœuds utilisent un ensemble de règles pour déterminer quelle transaction est la plus incitative à conserver. Ce comportement est connu sous le nom de Replace by Fee.

Il est intuitif que les mineurs maximisent les frais, mais pourquoi un opérateur de nœud non-mineur devrait-il mettre en œuvre ces politiques ? Comme indiqué dans le billet de la semaine dernière, l’utilité du pool de mémoire d’un nœud non-mineur est directement liée à sa similarité avec les pools de mémoire des mineurs. Ainsi, même si un opérateur de nœud n’a jamais l’intention de produire un bloc en utilisant le contenu de son mempool, il a intérêt à conserver les transactions les plus compatibles avec les incitations.

Bien qu’il n’y ait pas de règles consensuelles exigeant que les transactions paient des frais, les frais et le taux de frais jouent un rôle important dans le réseau Bitcoin en tant que moyen “équitable” de résoudre la concurrence pour l’espace des blocs. Les mineurs utilisent le taux de frais pour évaluer l’acceptation, l’expulsion et les conflits, tandis que les nœuds non mineurs suivent ces comportements afin de maximiser l’utilité de leurs mempools.

La rareté de l’espace des blocs exerce une pression à la baisse sur la taille des transactions et encourage les développeurs à être plus efficaces dans la construction des transactions. Le billet de la semaine prochaine explorera des stratégies et des techniques pratiques pour minimiser les frais dans les transactions sur la chaîne.

Modifications apportées aux services et aux logiciels clients

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

• ● Sortie du firmware 2.1.1 de Passport : Le dernier micrologiciel pour le dispositif de signature matérielle Passport prend en charge l’envoi aux adresses taproot, les fonctionnalités BIP85 et les améliorations apportées à la gestion des configurations PSBT et multisig.

• ● Lancement du portefeuille MuSig Munstr : Le logiciel Munstr bêta utilise le protocole nostr afin de faciliter les cycles de communication nécessaires à la signature des transactions multi-signatures MuSig.

• ● Le gestionnaire de plugins CLN Coffee est disponible : Coffee est un gestionnaire de plugins CLN qui améliore certains aspects de l’installation, de la configuration, de la gestion des dépendances et de la mise à jour des plugins CLN.

• ● Sortie d’Electrum 4.4.3 : Les dernières versions d’Electrum contiennent des améliorations du contrôle des pièces, un outil d’analyse de la confidentialité UTXO et la prise en charge des identificateurs de canaux courts (SCID), parmi d’autres corrections et améliorations.

• ● La suite Trezor prend en charge le coinjoin : Le logiciel Trezor Suite a annoncé la prise en charge des coinjoins qui utilisent le coordinateur de coinjoin zkSNACKs.

• ● Lightning Loop est par défaut MuSig2 : Lightning Loop utilise désormais MuSig2 comme protocole d’échange par défaut, ce qui permet de réduire les frais et d’améliorer la protection de la vie privée.

• ● Mutinynet annonce un nouveau signet pour les tests : Mutinynet est une enseigne personnalisée avec des blocs de 30 secondes qui fournit une infrastructure de test comprenant un explorateur de blocs, un faucet, ainsi que des nœuds LN de test et des LSP fonctionnant sur le réseau.

• ● Le Nunchuk ajoute coin control et la prise en charge du BIP329: Les dernières versions Android et iOS de Nunchuk ajoutent les fonctionnalités coin control et l’export de l’étiquette du portefeuille BIP329.

• ● Le portefeuille MyCitadel ajoute une prise en charge améliorée des miniscripts : La version v1.3.0 ajoute des fonctionnalités miniscript plus complexes, notamment les timelocks.

• ● Annonce d’un micrologiciel Edge pour Coldcard : Coinkite annonce un firmware expérimental pour le matériel de signature Coldcard, conçu pour les développeurs de portefeuilles et les utilisateurs chevronnés afin d’expérimenter de nouvelles fonctionnalités. La version initiale 6.0.0X inclut les paiements taproot keypath, les paiements multisig tapscript et la prise en charge de BIP129.

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.05 est la version la plus récente de l’implémentation du LN. Elle inclut la prise en charge des paiements en aveugle, la version 2 des PSBT, et une gestion plus souple des délais parmi de nombreuses autres améliorations.

• ● Bitcoin Core 23.2 est une version de maintenance pour la version majeure précédente de Bitcoin Core.

• ● Bitcoin Core 24.1 est une version de maintenance pour la version actuelle de Bitcoin Core.

• ● Bitcoin Core 25.0rc2 est une version candidate de la prochaine version majeure de Bitcoin Core.

Changements notables 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), Lightning BOLTs, et Bitcoin Inquisition.

• ● Bitcoin Core #27021 ajoute une interface pour calculer combien cela coûterait d’amener les transactions ascendantes non confirmées d’une sortie à un taux donné, une valeur connue sous le nom de fee deficit. Lorsque la sélection de pièces envisage d’utiliser une sortie particulière à une fréquence particulière, le déficit de frais de ses ascendants pour cette fréquence est calculé et le résultat est déduit de sa valeur effective. Cela décourage le portefeuille de choisir des produits fortement déficitaires pour une nouvelle transaction lorsque d’autres produits pouvant être dépensés sont disponibles. Dans un PR de suivi, l’interface sera également utilisée pour permettre au portefeuille de payer les frais supplémentaires (appelés bump fees) s’il doit de toute façon choisir des sorties déficientes, garantissant ainsi que la nouvelle transaction paie le taux effectif demandé par l’utilisateur.

  L’algorithme est capable d’évaluer les frais de majoration pour n’importe quelle constellation d’ascendants en évaluant l’ensemble de la grappe de transactions non confirmées de l’UTXO non confirmée et en élaguant les transactions qui auront été sélectionnées dans un bloc au niveau de la date cible. Une deuxième méthode permet de calculer un montant global pour plusieurs sorties non confirmées afin de corriger les éventuels chevauchements d’ascendances.

• ● LND #7668 ajoute la possibilité d’associer jusqu’à 500 caractères de texte privé à un canal lors de son ouverture et permet à l’opérateur de retrouver ces informations ultérieurement, ce qui peut l’aider à se souvenir de la raison pour laquelle il a ouvert ce canal en particulier.

• ● LDK #2204 ajoute la possibilité de définir des bits de fonctionnalité personnalisés pour l’annonce aux pairs, ou pour l’utilisation lors de la tentative d’analyse de l’annonce d’un pair.

• ● LDK #1841 met en œuvre une version d’une recommandation de sécurité précédemment ajoutée à la spécification LN (voir Newsletter #128) selon laquelle un nœud utilisant des sorties d’ancrage ne devrait pas tenter de regrouper des entrées contrôlées par plusieurs parties lorsque la transaction doit être confirmée rapidement. Cela permet d’éviter que d’autres parties puissent retarder la confirmation.

• ● BIPs #1412 met à jour BIP329 pour l’exportation d’étiquettes de portefeuilles avec un champ pour stocker les informations sur l’origine de la clé. En outre, la spécification suggère désormais une longueur maximale de 255 caractères pour les étiquettes.