Voila mon 2ème DIP sur un changement de format des documents du protocole.
Il est loin d’être terminé, mais je pense qu’une première phase de review est importante avant de rajouter plus d’éléments.
4 Likes
@nanocryk je suis en train de faire une revue complète de ton DIP sur le format des documents, comme je suis plus précis en français je t’explique ici mes modifs :
- remplacement de issuer par issuers partout
- En tête global : ajout du blockstamp, car tout les documents utilisent ce marqueur temporel, sauf les doc révocation et block. Comme ce champ est juste après le type, le programme saura que ce champ ne sera pas présent pour les type revocation et block tout simplement.
- Document Certification :
- Clarification des nom, ajout du préfixe target_ sur les champs qui concernent l’identité cible qui reçoit la certification
- Changement de issuer par pubkey car il s’agit de la clé publique de l’identité cible, pas de l’émetteur (qui est déjà dans l’entête commun)
- Document Transaction :
- renommage output_conditions -> unlock_conditions afin que les specs soient plus compréhensibles et plus proche du vocabulaire original, ça ne change rien sur le fond.
En concernant tes questions et remarques, non aucun champ n’est redondant mais on pourrait effectivement se baser sur le hash de l’identité plutot que sur le triplet (pubkey/uid/blockstamp) 
Enfin je pense qu’il est important de bien séparer le protocole blockchain de la couche réseau (que l’on peut aussi nommer protocole réseau mais attention a ne pas se mélanger les pinceaux !).
Les documents “peer” doivent donc être définis dans une DIPS a part spécifique a la couche réseau, si tu veut je m’en chargerai puisque je dev beaucoup sur w2p en ce moment, ce sera plus facile pour moi
J’en profite pour demander à @Inso : t’es-tu créé un mot de passe sur GitLab pour accéder à ton compte ? Je crois que tant que tu ne le fais pas, nous ne pouvons pas te mentionner dans les commentaires de Merge Request ou t’inviter pour la revue de code.
Je suppose que tu te connectes avec la connexion GitHub.
Intéressant…
Dans les options de compte je n’ai pas de définition de mdp ?
Maintenant que tu t’es connecté avec Github tu peux aller cliquer sur ton profil en haut à droite, puis Settings. Ensuite tu vas dans Password et tu peux le définir. Ensuite il faudra que tu te connecte directement avec ton username/mail et ton mot de passe, sans utiliser la connection Github
A priori j’avais déja un mdp défini, mais je l’ai changé. Dites moi ce que ça donne ?
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 !
2 Likes
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.
3 Likes
Il me semble qu’il faudrait aussi préciser l’endianness
4 Likes
Ajouté !
1 Like
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)
2 Likes
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 !
1 Like
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.
1 Like