Bon en fait j’avais sûrement tout faux, car ça n’a rien changé.
Par contre je viens de t’ajouter au groupe nodes/common en tant que “Developer”, et là on peut t’inviter.
À noter que tu es admin, hein, tu changes ce rôle si tu veux 
cc @florck qui pourra nous confirmer ce comportement !
Je confirme, si tu fais connexion github tu ne crées pas de password, si ensuite tu veux te connecter sans passer par la connexion github, il te faut définir un password dans tes settings personnels (par le menu en haut à droite).
En tout cas je trouve que le procédé de merge request/review est très adapté pour ce genre de contributions. Vu qu’on peut commenter à une certaine position dans le code, il devient beaucoup plus simple de débattre sur une proposition et de suivre les conversations.
Il me semble qu’il faudrait aussi préciser l’endianness
Ajouté !
Les DIP0001 et DIP0002 ont besoin d’une nouvelle review complète suite à l’ajout du support de multiples cryptosystèmes (pas que Ed25519). (merci @elois pour l’idée)
oui j’ai vu je ferai une revue complète dans la soirée mais la je suis sur des travaux prioritaires pour la 1.6 !
hop review complèt’e faite, je n’ai pas vu d’erreur 
Super. Cet ajout te semble utile et pas trop complexe ?
Ce qui est cool ce que pour les simples portefeuille ça fait office de masquage de la clé publique :3
Je ne sais pas, c’est plus complexe mais de toute façon a un moment ou un autre on aura ce problème de changement d’algo de crypto alors quitte a refondre le protocole autant traiter ce cas dans la foulée 
Lors de la consommation des sources la clé publique est dévoilée, mais effectivement avec une fonction Pay To Pubkey Hash on peut masquer la pubkey du wallet alimenté mais c’était déjà le cas avant il me semble 
P2PH est déjà dans le protocole courant ?
Sinon oui ça fait office de P2PH mais avec n’importe quel algo.
Par contre ça va demander pas mal de réflexions sur comment assurer la transition.
Tout comme revocationLegacy il faut un format spécial pour les inputs qui accepte les anciennes sources
Pour les anciennes sources on va convertir “virtuellement” les anciennes conditions en script. Pas besoin de le faire manuellement, et on dépense avec le nouveau format.
Si un jour on ajoute les blocks snapshots on pourra petit à petit supprimer ces options de compatibilité. Pour le doc de revocation on peut partir sur 2 fois la durée de vie d’un humain, je pense que dans 160 ans tous les issuers de compte membres ne seront plus là xD
Document réécrit dans un format beaucoup plus lisible et détaillé, n’hésitez pas à passer le lire et le commenter
(Merci de bien vouloir commenter les lignes et non les commits pour pouvoir marquer les discussions comme résolues)
EDIT : Je travaille maintenant sur les conditions de validité des blocks, mais je ne comprends pas toute la syntaxe. D’où viennes ces champs ? C’est du SQL ? @cgeek
EDIT 2 : J’ai voulu corrigé une erreur dans Protocol.md et j’ai pu commit direct sur master. C’est pas trop grave car c’est juste une correction de la doc, mais bon je devrais pas pouvoir le faire sans passer par une Merge Request.
Oui derrière tout est indexé dans une base SQLite
En fait c’est le cas, j’ai protected la branche mais comme tu est Master du dépôt tu n’a pas de limitations !
J’en profite pour rajouter l’idée de la blockchain limitée dans le temps (ou blockchain glissante) voir à ce sujet : http://www.creationmonetaire.info/2016/05/linfini-dans-une-taille-finie.html
L’idée est la suivante : tous les ans, un block zéro nouveau est généré, (block zéro glissant) qui reprend la blockchain de -10 ans à -5 ans, pour générér une BDD(- 5 ans) reprenant toutes les informations utiles.
Ce block devient la nouvelle référence initiale des blocks suivants.
Il n’y a ainsi plus aucune nécessité de stocker la blockchain antérieure à -5 ans, et notre masse de données sera ainsi parfaitement finie, pour toujours (étant donné que même la masse de nombres est glissante, déjà inscrite comme telle dans le protocole actuel).
A noter que si on prend 5 ans pour générer un tel block, rien ne presse pour implémenter une telle feature, on a encore 4 ans pour le faire, mais y réfléchir permettra peut-être de le réaliser plus facilement que sous la pression d’un problème de masse critique plus tard.
Je pensais à la création d’un tel block “snapshot” tout les 2 ans (ou plus), avec la conservation d’au maximum 2 blocks snapshot. Ces blocks n’a alors même pas besoin de stocker les certifications/“membership” pour lesquelles il faudrait stocker les durées restantes. Il n’aura donc a stocker que les transactions avec des outputs non dépensés.
Oui, 2 blocs snapshot sont nécessaires :
Au bloc 0 + N, Snapshot1. Un nouveau calculateur peut reparcourir toute la chaine pour vérifier la validité de ce snapshot.
A Snapshot1+N, Snapshot2. On commence à oublier les blocs qui précèdent Snapshot1, et pour un nouveau calculateur, c’est une hypothèse de sécurité raisonnable que de penser que si N blocs ont été validés après Snapshot1, c’est que ce Snapshot1 était valide.
Il me semblait qu’il était approuvé/proposé qu’une option dans Duniter pouvait être choisi pour garder les informations de la blockchain depuis le début? A ce jour nous ne pouvons pas présumer des applications/utilisations qui nécessiteraient de ne pas garder les information antérieur à -5ans.
Tu peux d’ores et déjà stocker tous les blocs, et rien ne pourra jamais empêcher se stocker tous les blocs, ça n’a rien à voir avec le sujet relevé ici.