Elle ne sera pas rejetée mais évaluée comme B ou C, cependant il ne faut pas faire cela, je suis d’avis qu’un tel document devrait être rejeté, voici pourquoi :
Le comportement d’une tel combinaison pouvant dépendre des implémentations il conviens de toujours spécifier explicitement la priorité via des parenthèses, en effet un même script de conditions de déblocage doit pouvoir être utilisé par plusieurs programmes, y compris des clients, et être toujours interprété de la même façon, il est donc prohibée de se baser sur la priorité implicite des opérateurs entre eux, c’est trop risqué !
La règle est déjà explicite il me semble : il n’y a pas de priorité entre opérateurs, et la lecture se fait de gauche à droite.
Donc dans : SIG(1) && SIG(2) || SIG(3)
On évalue :
SIG(1) && SIG(2) = A
puis
A || SIG(3) = B
On évalue alors B pour savoir si la condition de déverrouillage est remplie.
Après l’utilisation de parenthèses permet de s’assurer du respect de la priorité désirée, et c’est certainement une bonne pratique pour les clients. Mais je ne vois pas de besoin d’interdire quoi que ce soit ici.
Note: si j’ecris en unlock : 0:XHX(1234) <=> je tombe bien sur un wrong unlocker , ce qui est attendu … juste pour signaler a priori que je n’ai pas de champs dans le document qui font défaut.
@Max pour un parseur de code, une parenthèse n’est pas un caractère anodin… il te faut au moins protéger le mot de passe avec des (double) quotes. Et que se passerait-il si tu avais une parenthèse fermante dans le mot de passe? Comment un parseur pourrait-il savoir quelle parenthèse est la bonne pour terminer le terme qu’il est en train d’isoler?
Ah oui d’accord … bon sur le principe Duniter accepte ce mot de passe pour la fonction XHX (je viens de tester dans le fichier grammar-test.js), par contre effectivement tu t’exposes à des erreurs incompréhensibles en mettant une parenthèse précisément à cet endroit où une parenthèse fermante à la fin.
Là tu vas te prendre des erreurs à la réception de la TX, il se peut même qu’aucun bloc contenant ce mot de passe de déverrouillage ne soit accepté, rejetant celui-ci sur sa forme. Sur le fond par contre, pas de soucis.
j’ai justement ecris la un cas d’exception qui peut arriver si l’application client ne fais pas attention en amont du mot de pass choisis avant le sha256,
duniter ne voit que le je sha256 donc l’accepte sans probleme, c est normal
par contre , pour moi, c’est duniter qui sur une expression telle que XHX((1234) dans l’unlock de la future transaction
doit prendre la premiere parenthese a cote du X
XHX(
puis aller jusqu’a la derniere parenthese fermante
)
pour extraire le mot de passe
(1234
Je rappel que ma transaction a etait validé dans un block
la il me semble que ca pose probleme, je ne peut pas deverouiller pour utiliser la ressource
Un dev mal intentionné peut shunter n’importe quel document, en les envoyant vers une clé publique aléatoire.Pas besoin de jouer avec la fonction XHX pour ça…
Qui va-t-on pointer du doigt si toutefois ce cas arrive ?
Le logiciel client, qui n’est qu’une porte d’entrée …
Duniter, le coeur du systeme…
Les deux seront mis en cause et a mon avis a plus forte raison le coeur du systeme…
tout autant qu’il me semble indécent de proposer aux utilisateurs sans capacité d’analyse des codes sources des logiciels clients de leur dire : “vous avez un doute ? jetez un oeil sur le code”
Me concernant, je fais mon applis, donc peu m’importe ce que propose les autres logiciels à qui je ne jette pas la pierre, je peux gérer ce cas particulier, no problemo
Je pense également au fait que rien n’empeche de s’approprier les sources de ces applis clients, shunté le bouzin, proposer sous un même nom cette appli, en stipulant que c’est bien le code originel de l’auteur qui de faite, sera pointé du doigt…
Au final , si le parsing est effectué côté Duniter , la question est réglée.
Mais le problème existe sur toutes les crypto. Un logiciel client qui envoie la monnaie vers l’adresse AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA, tu vas demande au “coeur du système” de vérifier que c’est une véritable adresse dont quelqu’un connait la clé ?
