La newsletter de cette semaine partage une analyse sur la synchronisation des nœuds complets sans anciens témoins. Sont également incluses nos sections régulières avec des descriptions des discussions sur le changement de consensus, annonçant de nouvelles versions et versions candidates, et décrivant les changements notables apportés aux logiciels d’infrastructure Bitcoin populaires.

Nouvelles

• ● Synchronisation des nœuds complets sans témoins : Jose SK a publié sur Delving Bitcoin un résumé d’une analyse qu’il a réalisée concernant les compromis de sécurité permettant aux nœuds complets nouvellement démarrés avec une configuration particulière d’éviter de télécharger certaines données historiques de la blockchain. Par défaut, les nœuds Bitcoin Core utilisent le paramètre de configuration assumevalid qui saute la validation des scripts dans les blocs créés plus d’un mois ou deux avant la sortie de la version de Bitcoin Core utilisée. Bien que désactivé par défaut, de nombreux utilisateurs de Bitcoin Core définissent également un paramètre de configuration prune qui supprime les blocs un certain temps après les avoir validés (la durée de conservation des blocs dépend de la taille des blocs et du paramètre spécifique sélectionné par l’utilisateur).

  SK soutient que les données de témoins, qui sont uniquement utilisées pour la validation des scripts, ne devraient pas être téléchargées par les nœuds élagués pour les blocs assumevalid car ils ne les utiliseront pas pour valider les scripts et finiront par les supprimer. Omettre le téléchargement des témoins “peut réduire l’utilisation de la bande passante de plus de 40 %”, écrit-il.

  Ruben Somsen soutient que cela change le modèle de sécurité dans une certaine mesure. Bien que les scripts ne soient pas validés, les données téléchargées sont validées contre l’engagement du merkle root de l’en-tête du bloc à la transaction coinbase jusqu’aux données du témoin. Cela garantit que les données étaient disponibles et non corrompues au moment où le nœud a été synchronisé initialement. Si personne ne valide régulièrement l’existence des données, il pourraient être concevable qu’elles soient perdues, comme cela s’est produit pour au moins un altcoin.

  La discussion était en cours au moment de la rédaction.

Modification du consensus

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

• ● Rapport sur l’informatique quantique : Clara Shikhelman a publié sur Delving Bitcoin le résumé d’un rapport qu’elle a co-écrit avec Anthony Milton sur les risques pour les utilisateurs de Bitcoin des ordinateurs quantiques rapides, un aperçu de plusieurs voies vers la résistance quantique, et une analyse des compromis impliqués dans la mise à niveau du protocole Bitcoin. Les auteurs trouvent que 4 à 10 millions de BTC sont potentiellement vulnérables au vol quantique, certaines mesures d’atténuation sont possibles maintenant, l’exploitation minière de Bitcoin est peu susceptible d’être menacée par l’informatique quantique à court ou moyen terme, et la mise à niveau nécessite un large accord.

• ● Limite de poids de transaction avec exception pour prévenir la confiscation : Vojtěch Strnad a publié sur Delving Bitcoin pour proposer l’idée d’un changement de consensus pour limiter le poids maximum de la plupart des transactions dans un bloc. La règle simple ne permettrait qu’une transaction de plus de 400 000 unités de poids (100 000 vbytes) dans un bloc s’il était la seule transaction dans ce bloc à part la transaction coinbase. Strnad et d’autres ont décrit la motivation pour limiter le poids maximum de la transaction :

  • Optimisation plus facile du modèle de bloc : il est plus facile de trouver une solution presque optimale au problème du sac à dos lorsque les éléments sont plus petits par rapport à la limite globale. Cela est en partie dû à la minimisation de la quantité d’espace restant à la fin, avec des éléments plus petits laissant moins d’espace inutilisé.

  • Politique de relais plus facile : la politique pour le relais des transactions non confirmées entre les nœuds prédit quelles transactions seront minées afin d’éviter le gaspillage de bande passante. Les transactions géantes rendent les prédictions précises plus difficiles car même un petit changement dans le taux de frais le plus élevé peut les faire retarder ou être évincées.

  • Éviter la centralisation de l’extraction : s’assurer que les nœuds complets de relais peuvent gérer presque toutes les transactions empêche les utilisateurs de transactions spéciales de devoir payer des frais hors bande, ce qui peut conduire à la centralisation de l’extraction.

  Gregory Sanders a noté qu’il pourrait être raisonnable de simplement appliquer une limite maximale de poids par un soft fork sans aucune exception basée sur les 12 années de politique de relais cohérente de Bitcoin Core. Gregory Maxwell a ajouté que les transactions dépensant uniquement des UTXOs créés avant le soft fork pourraient être autorisées une exception pour prévenir la confiscation, et qu’un soft fork transitoire permettrait à la restriction d’expirer si la communauté décidait de ne pas la renouveler.

  Des discussions supplémentaires ont examiné les besoins des parties souhaitant de grandes transactions, principalement les utilisateurs de BitVM à court terme, et si des approches alternatives étaient disponibles pour eux.

• ● Suppression des sorties de l’ensemble UTXO basée sur la valeur et le temps : Robin Linus a posté sur Delving Bitcoin pour proposer un soft fork pour retirer les sorties de faible valeur de l’ensemble UTXO après un certain temps. Plusieurs variations de l’idée ont été discutées, les deux principales alternatives étant :

  • Détruire les fonds économiquement non rentables anciens : les sorties de petite valeur qui n’avaient pas été dépensées pendant longtemps deviendraient inexploitables.

  • Exiger que les fonds économiquement non rentables anciens soient dépensés avec une preuve d’existence : utreexo ou un système similaire pourrait être utilisé pour permettre à une transaction de prouver que les sorties qu’elle dépense font partie de l’ensemble UTXO. Les sorties anciennes et économiquement non rentables devraient inclure cette preuve, mais les sorties plus récentes et de plus grande valeur seraient toujours stockées dans l’ensemble UTXO.

  L’une ou l’autre solution limiterait efficacement la taille maximale de l’ensemble UTXO (en supposant une valeur minimale et la limite de 21 millions de bitcoins). Plusieurs aspects techniques intéressants d’une conception ont été discutés, y compris des alternatives aux preuves utreexo pour cette application qui pourraient être plus pratiques.

Mises à jour et versions candidates

Nouvelles mises à jour et versions candidates pour des projets d’infrastructure Bitcoin populaires. Veuillez envisager de passer aux nouvelles versions ou d’aider à tester les versions candidates.

• ● Core Lightning 25.05rc1 est un candidat à la sortie pour la prochaine version majeure version de cette populaire implémentation de nœud LN.

• ● LND 0.19.1-beta.rc1 est un candidat à la version pour une maintenance version de cette populaire implémentation de nœud LN.

Changements de code et de documentation notables

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 #32582 ajoute de nouveaux journaux pour mesurer la performance de reconstruction de bloc compact en suivant la taille totale des transactions qu’un nœud demande à ses pairs (getblocktxn), le nombre et la taille totale des transactions qu’un nœud envoie à ses pairs (blocktxn), et ajoutant un horodatage au début de PartiallyDownloadedBlock::InitData() pour suivre combien de temps l’étape de recherche dans le mempool prend seule (dans les modes à bande passante élevée et faible). Voir le Bulletin #315 pour un rapport de statistiques précédent sur la reconstruction de bloc compact.

• ● Bitcoin Core #31375 ajoute un nouvel outil CLI bitcoin -m qui enveloppe et exécute les binaires multiprocess bitcoin node (bitcoind), bitcoin gui (bitcoinqt), bitcoin rpc (bitcoin-cli-named). Actuellement, ceux-ci fonctionnent de la même manière que les binaires monolithiques, sauf qu’ils prennent en charge l’option -ipcbind (voir le Bulletin #320), mais les améliorations futures permettront à un opérateur de nœud de démarrer et arrêter les composants indépendamment sur différentes machines et environnements. Voir le Bulletin #353 dans la section Bitcoin Core PR Review Club couvrant ce point.

• ● BIPs #1483 fusionne BIP77 qui propose payjoin v2, une variante asynchrone sans serveur dans laquelle l’expéditeur et le récepteur passent leurs PSBTs chiffrés à un serveur annuaire payjoin qui stocke et transmet uniquement les messages. Comme l’annuaire ne peut ni lire ni modifier les charges utiles, aucun des portefeuilles n’a besoin d’héberger un serveur public ou d’être en ligne en même temps. Voir le Bulletin #264 pour un contexte supplémentaire sur payjoin v2.