Ici on a la fonction exact(condition) qui ajoute ^ et $ autour de la condition, donc on est bon :
TX_OUTPUT_SIG: exact(SIG)
Dans https://git.duniter.org/clients/cesium-grp/cesium/blob/master/www/js/services/tx-services.js
On execute TX_OUTPUT_SIG qui est défini comme exact(SIG), donc tout va bien…
var sigMatches = BMA.regexp.TX_OUTPUT_SIG.exec(outputCondition);
Le code qui suit me paraît bon, car il fait un match exact avec début et fin de ligne, donc si une autre condition est ajoutée la source ne matche pas.
Dans https://git.duniter.org/clients/cesium-grp/cesium/blob/master/www/js/entities/block.js
function exact(regexpContent) {
return new RegExp("^" + regexpContent + "$");
}
Block.prototype.regexp = {
TX_OUTPUT_SIG: exact("SIG\\(([0-9a-zA-Z]{43,44})\\)")
};
Ici on a une petite boulette sans conséquence, où il faudrait utiliser Block.prototype.regexp.TX_OUTPUT_SIG.exec(unlockCondition);
mais sinon la regexp est la même, donc test strictement un seul SIG()…
var amount = parts[0];
var unitbase = parts[1];
var unlockCondition = parts[2];
var matches = Block.prototype.regexp.TX_OUTPUT_SIG.exec(parts[2]);
Etrange, le bug doit être ailleurs. Il faudrait poser des breakpoints…
[edit]
En fait il me semble que ce code refusent les sources ayant des conditions additionnelles. Ce qui a pour effet de les bloquer. Ce qui est normal. En fait je ne voit là rien de grave pour les comptes dans Duniter, juste qu’il n’existe aucun client qui accepte les sources ayant des conditions de dépense multiples.
Mais la solution ne doit pas être d’accepter des sources dont seule une partie est valide. Il faut implémenter la totalité des conditions existantes dans les clients pour débloquer les sources et donc les comptes.
Je ne sais pas si je suis clair ni logique, corrigez moi si je me trompe.