Ok grâce aux tests de @Moul on a confirmation que Duniterpy utilise une lib de crypto iso avec la norme Ed22519 tout comme Dunitrust :
Ce qui veut dire qu’environ 1 document sur 2^64 signé par silkaj/sakia est rejeté par Duniter, c’est sans doute déjà arrivé sans qu’on s’en rende compte (une transaction qui ne passe pas pour raison inconnue, on la refais quelques blocs plus tard et ça passe car le hash du document n’est plus le même, le blockstamp ayant changé).
Je pense que nous avons suffisamment d’éléments pour prendre la décision de corriger Duniter.
Je propose de remplacer naclb par tweetnacl-js pour 3 raisons :
- Le code de tweetnacl-js a été audité : GitHub - dchest/tweetnacl-js: Port of TweetNaCl cryptographic library to JavaScript
- tweetnacl-js est une réécriture en asm.js du code C de la lib tweetnacl. Ce qui permettra de garder de bonnes performances (perf d’asmjs quasiment natives) tout en simplifiant et accélérant le build et le packaging de Duniter (une lib C en moins a compiler).
- Ça reste aussi léger que TweetNaCl, ce qui permet de garder une lib de crypto minimaliste et légère.
Voici comment je compte procéder :
- Ajout de tweetnacl-js dans Duniter 1.7.20 (en conservant naclb) et utilisation de tweetnacl-js pour les blocs v12, déclenchement automatisé via nonce.
- Test du passage en V12 sur la g1-test uniquement.
- Si tout s’est bien passé sur la g1-test, lancement de l’appel a installer la 1.7.20 sur la G1 puis attente du passage automatique en V12 sur la G1.
- Quand le passage en V12 s’est bien passé sur la G1, livraison d’une nouvelle release de Duniter qui supprime naclb et qui ne vérifie plus les signatures des bloc v10 et v11.
@cgeek ce plan te conviens t’il ? Si oui je compte prioriser ce chantier au plus tôt, c’est à dire arrêter Dunitrust et consacrer mes prochains WE au développement de cette proposition 