clé publique+lib crypto pour déchiffrer la signature, on obtient normalement a la sortie quelque chose qui doit être égal au hash sha 256 du document transaction, si c’est différent c’est que la signature est invalide, soit le client s’est tromper dans son code pin sont les données de sa puce sont corrompus.
1 Like
C’est pas mal, il y a juste “<<< envoi vers SHA256” et sa boîte noire associée “SHA256(TX)” qui en fait n’existent pas.
La signature par la lib de crypto peut se faire sur l’entièreté de la transaction (Version\n...). Pour les blocs c’est vrai qu’on passe par une moulinette de SHA256 pour réduire sa taille, mais pour les transactions on ne le fait pas.
Pour l’explication technique pour les blocs : la signature Ed25519 coûte très cher en CPU, et son coût est directement fonction de la taille des données à signer. Si l’on ne hachait pas le bloc avant signature, alors les gros blocs mettraient sensiblement plus de temps à apparaître que ceux avec peu de données du fait de la preuve de travail.
Bref, on donnerait un handicap aux blocs qui font le plus vivre le réseau. Ce qu’on ne veut pas bien évidemment !
Quand tu auras produit les graphiques que tu voulais, on les mettra dans le Wiki !
vous allez me rendre chèvre 
j’étais prêt à sabrer le champagne 
2 Likes
C’est superbe ce que tu es en train de nous produire là 
Oui mais n’es-tu pas satisfait d’avoir enfin ces tant attendus graphiques, qu’en plus tu vas pouvoir partager à d’autres nouveaux arrivants souhaitant la même compréhension que toi ?
N’auras-tu pas fait grandement avancer le projet Duniter de cette façon ?!
C’est une super contribution ce que tu fais
1 Like
la on est ok ?
3 Likes
Oui mais les emplacement choisis me semblent trompeurs, ainsi il serait plus judicieux de placer a gauche tout les éléments fournis par A (celui qui paye) et a droite tout les éléments fournis par B (celui qui reçoit), car là quelqu’un qui regarde ce graphique et qui ne connais pas peut s’emmêler les pinceaux.
bravo pour ce graph !
plutot que ID, j’aurais mis salt, pour ne pas confondre avec l’UID qui sert à identifier l’utilisateur. Le salt, lui, reste secret.
A noter également (je sais pas si c’est important) que le salt+pass sont d’abord transformé en seed, par la lib Scrypt, et ensuite passé à la lib de crypto NaCL. Les deux lib sont complémentaires.
1 Like
oui ca l’est 
le salt, en deux mots , c’est quoi ?
Comment a partir de mon identifiant et mot de pass je me retrouve jusqu’a ma case bleu ID ?
l’UID => sert a identifier l’user, a partir de quoi ? et comment il est generer ?
Bon en fait c’est des quiproquo de langages :
salt = identifiant secret dans cesium = Key’s salt dans duniter = secret key dans sakia
Ta case bleu ID ont te propose de remplacer le mot ID par le mot salt c’est tout
Et la 1ere case libcrypto tu peut préciser si tu veut que c’est la lib scrypt, cette lib donne une seed (graine) donc la private key est un dérivé déterministe tu peut donc rajouter une case seed entre la 1ere case libcrypto et la case priv_key_a.
A noter que dans le cas d’un système puce/carte client cette première étape peut être faite lors de l’initialisation de la puce/carte, pas besoin de la refaire a chaque transaction 
1 Like
@elois comme il y aura tout un tas de solutions envisageable a mettre en oeuvre, selon les implementations [ technique / coût ] pour le cadre « CB/TPE » je ne fais pas la distinction de qui peut faire quoi 
.
En tout cas, ca nous donne une base de référence sur laquelle communiquer 
ceci étant, derniere mouture… jusqu’a ce que je démonte entièrement le code 
1 Like
je suis chiant mais je remplacerai “check datas integrity” par “check signature validity”
1 Like
honnêtement non, je ne vois pas tous instantanément ,des fois je ne remarque certaines erreurs qu’après 
Vendu !
En passant, tu peux modifier ce fichier svg sur ce site la:
http://editor.method.ac
et le sauvegarder a nouveau en svg pour le partager
2 Likes
yop,
au vu du retour de l’appel a tx/sources/pubkey :
-
la clé “conditions” de l’objet JSON , cette information me sert a quoi -si ce n’est de me rajouté de la data pour le plaisir - ?
ici, cette clé “conditions” n’est pas présente :
https://github.com/duniter/duniter/blob/master/doc/HTTP_API.md#txsourcespubkey
et “in real life” elle l’est.
https://g1.duniter.org/tx/sources/5cnvo5bmR8QbtyNVnkDXWq6n5My6oNLd1o6auJApGCsv -
donc partant du principe qu’au fur et a mesure de nouvelles transactions, cette liste de sources ne fait que s’incrementer, ca va sévèrement piquer a un moment donné pour le traitement de cette liste et check si pubkey a suffisament de fond pour depenser sa monnaie ? je me trompe ?
(je sais que duniter ne renvois pas les sources déjà consommées…, il me semble) (dans le cadre de traitement par des “petits” mcu, ainsi que la notion de bande passante pour la connectivité internet)
@max l’opération de génération du doc de transaction peut très bien être déléguée a un serveur tier pusqu’elle n’est pas sensible, ce n’est pas un problème 
1 Like
Oui, c’est vrai qu’en interne, plus le temps passe, et plus il va y avoir de sources à vérifier, mais quand c’est fait en local par une requête sur une base de données, ça se sent pas. C’est exactement le même problème avec n’importe quel système qui tourne sur une blockchain. Ici, je ne pense pas que les nœuds se demandent ce genre d’informations par BMA, puisqu’ils les ont déjà!
Et puis, à terme on devrait pouvoir avoir des “savepoints” (en tout cas il me semble que c’est l’un des systèmes les plus simples pour régler les problèmes de montée en charge sur le long terme, et @cgeek l’a déjà mentionné), et donc de retomber avec un nombre raisonnable de sources à chaque fois.
C’est ce que j’en comprends en tout cas, tapez-moi dessus si je n’ai rien compris. 
Da 
, je vois bien, j’y réfléchis tout de même si je ne souhaite pas délégué cette opération de “composition du document” ou plutot preciser que ce sont des unités de traitement pas tres performante niveau rapidité, de vieux cpu / des mcu qui doivent faire le job
Oui @jytou j’entends bien ,
C’est dans le cadre ou mon materiel qui le réalise n’execute pas Duniter et fait bien une requete exterieur sur le reseau a un noeud.
A partir de la, si il peut exister une requete qui me retourne, amount et base, - seules informations nécessaire si je ne m’abuse pour check le solde [et peut etre une info telle la pubkey, au cas ou quelqu’un modifie les données entre duniter => moi et me fait faire tout le traitement dans le vent ] , j’y gagne sur le traffic réseau en bande passante et en traitement des données.
un octet, c’est déjà 8 bits de trop 
d’où
de la meme maniere concernant l’information du hash du block pour faire mon document de transaction, une requete sur le block courrant avec en retour juste le hash relatif au block, ce serait cool
1 Like