# Duniter utilise une ancienne version buggée de TweetNaCl: que faire? **URL:** https://forum.duniter.org/t/duniter-utilise-une-ancienne-version-buggee-de-tweetnacl-que-faire/6633 **Category:** Duniter-v1 **Tags:** duniter, dunitrust, crypto **Created:** [4 December 2019 00:56 UTC](https://forum.duniter.org/t/duniter-utilise-une-ancienne-version-buggee-de-tweetnacl-que-faire/6633 "2019-12-04T00:56:14Z") **Posts on this page:** 1 **Showing post:** 57
### Author: ![Moul](https://forum.duniter.org/user_avatar/forum.duniter.org/moul/32/9145_2.png) [@Moul](https://forum.duniter.org/u/Moul) #### Post date: [29 January 2020 14:41 UTC](https://forum.duniter.org/t/duniter-utilise-une-ancienne-version-buggee-de-tweetnacl-que-faire/6633/57 "2020-01-29T14:41:21Z")
Pour moi oui. On pourra faire de même avec [Verify a block signature with DuniterPy](https://forum.duniter.org/t/verify-a-block-signature-with-duniterpy/6635). Je propose de le faire à l’occasion de l’annonce de la 1.7.20 pour la mise en production sur la Ğ1-Test. Ça permettra aux forgeurs de comprendre la raison de ce changement de protocole, pour ensuite l’appliquer à la Ğ1. Maintenant que Silkaj est basé sur DuniterPy 0.56, qui implémente la vérification de blocs, je vais pouvoir publier [la commande de vérification des blocs en masse](https://git.duniter.org/clients/python/silkaj/issues/262). * * * Je fais un aparté, mais j’ai pas bien compris la solution à ce problème : > [@elois](#): > > Je vois bien une solution de contournement, j’aimerais savoir ce que tu en penses : > > On pourrait laisser `proof.ts` inchangé mais seulement utilisé la fonction verify non buggée en validation locale des blocs v12. Ainsi, si le noeud génère par malchance un bloc avec sig invalide (1 chance sur 2^64), il va refuser son propre bloc, est ce que ça te semble ok comme solution ? Quelle a été la solution retenue ? --- _[View the full topic](https://forum.duniter.org/t/duniter-utilise-une-ancienne-version-buggee-de-tweetnacl-que-faire/6633)._