Bug de cesium : Implémentation dépense de sources CSV() et CLTV()

Rah, tu as été plus rapide que moi à faire joujou avec ces conditions.
Je me disais bien qu’il y aurait de telles choses délectables à découvrir :wink:

Intéressant de savoir que Césium implémente déjà ces conditions.
Mais, vu ce que tu remontes, c’est bugé.

Avec quelques junes (N × 0.01 Ğ1 = 22,40 Ğ1), un Silkaj qui génère des transactions avec ces conditions, un algorithme pour envoyer de telles transactions en masse aux comptes membres récupérés préalablement via BMA, et cette personne a de quoi faire râler la communauté Ğ1/Césium et obliger son développeur à implémenter en urgence l’algorithme de sélection de sources ou faire comme Silkaj et lire que les sources avec condition unique SIG().

3 Likes

Vu ce que je rapporte, c’est plutôt que, là où Silkaj gère les outputs avec UNIQUEMENT UN SIG() ; Cesium gère les outputs avec SIG() et ne regarde pas plus loin (si cet output est dépensable ou non). D’où ce bug.

N * 0.01 ?

Je crois qu’il y a des façons plus polies de faire. Mais il est faux d’affirmer que je n’y ai pas pensé tout de suite :smiling_imp:

1 Like

Attention a ne pas confondre ce que fait Césium et ce que fait Duniter.
En l’occurrence, Cesium ne sais pas dépenser une source autrement qu’en signant avec SIG.
J’ai juste géré l’affichage des conditions dans l’explorateur de blocs, et commencé a y réfléchir, mais j’en étais resté la, faute d’utilisateur pour tester cela (et surtout de besoin réels).

Si tu as pu dépenser une source qui avait été bloqué, c’est simplement parce-que Duniter l’a renvoyer dans sa liste de sources utilisable, je suppose.

N’est-ce pas plus simple pour de rechercher sa s le code source ? C’est pas si compliqué le JS :slight_smile:

@kimamila Je pense que tu as lu le premier post, et non ce message qui détaille le bug.

Non, je dis que :

Si j’envoie une tx avec condition de lock sur un compte, je peux bloquer toutes les dépenses depuis ce compte faites depuis Cesium, ou en tout cas rendre ce compte inutilisable depuis Cesium.

J’ai également dit que :

Je peux envoyer une tx valide une fois que le délai CSV est passé. Duniter fait donc ce qu’on lui demande.

On est d’accord, par contre il essaie d’utiliser des sources qui ont des conditions de lock supplémentaires. Ceci fait que la tx n’est pas valide… Ce qui bloque la dépense, même s’il y a assez de monnaie sur le compte.

Je peux bloquer le compte portefeuille de ton choix (je n’ai pas essayé les comptes membres) si tu veux un cas à étudier.

Sans doute, mais j’apprends déjà Python.

2 Likes

Pour info, j’ai un peu regardé le code, si des devs JS passent par là :

Je ne sais pas coder en JS, cependant je peux vous indiquer les lignes qui me semblent poser souci (v1.4.2) :

5679 :
TX_OUTPUT_SIG: exact(SIG)

7506 :
 var sigMatches =  BMA.regexp.TX_OUTPUT_SIG.exec(outputCondition);

10859 : 
Block.prototype.regexp = {
  TX_OUTPUT_SIG: exact("SIG\\(([0-9a-zA-Z]{43,44})\\)")
};

10881 :
 var matches =  Block.prototype.regexp.TX_OUTPUT_SIG.exec(parts[2]);

En gros, le regexp cherche exactement SIG(pubkey) parmi les outputs reçus, et utilise tout ce qu’il trouve. Dont Cesium va utiliser AUSSI des sources avec conditions de lock non satisfaites, parce qu’il y a effectivement exactement SIG(pubkey) dedans (mais pas que).

J’ai un peu expérimenté, je crois que ceci ne bloque pas les sources D.U., par contre cela bloque les sources recues.

Pour comparaison, la ligne correspondante dans Silkaj est :

    for source in sources["sources"]:
        if source["conditions"] == "SIG(" + pubkey + ")":
2 Likes

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.

1 Like

C’est violent :worried:

3 Likes

Le comportement que j’observe est : Cesium essaie d’utiliser des sources bloquées, mais reçoit un “wrong unlocker in transaction”. Cesium ne fait pas le tri des sources. Ceci n’a rien de grave pour les comptes dans Duniter, mais est bien plus grave pour l’économie Ğ1 vu la position dominante de Cesium et l’exposition de tous les comptes à cette attaque.

Le souci, c’est que ça bloque également les sources qui n’ont pas de conditions de dépenses.

Pour confirmer, vous pouvez essayer d’envoyer des tx sur Cesium depuis le compte 6etdjZMRV8p5e5V7AAu4ewChoS3vWrhbh7jn7ZL5g3X6 : id/mdp 123456789 (blocage d’ici samedi 26). Sur la GTest uniquement. Seuls 2*100 GT sont bloquées pour Duniter, mais Cesium bloque tout.

J’ai ma version de Silkaj qui me permet de bloquer un compte sans sommation avec du CSV(), mais je préfère ne pas la publier. Demandez-moi de bloquer des comptes GT si vous le souhaitez.

Pour moi, il est sain de proposer une solution de court terme (utiliser uniquement les sources SIG(pubkey) qui évite cette attaque à court terme, et prévoir de développer l’algo pour traiter tous les cas de déblocage des sources à moyen terme.

Je prévois de me pencher sur ce problème pour Silkaj courant Novembre.

2 Likes

Je plussoie à 200% :slight_smile:

Ce serait peut-être l’occasion de lancer un système de bug bounty afin de rémunérer en Ğ1 ceux qui fixerai des bug dans cesium. L’idée est d’indiquer un montant en Ğ1 sur l’issue correspondante, iel contributeur.ice qui corrigera le bug percevra le montant indiqué sur la clé publique de son choix.

Qu’en dit tu @kimamila ? Tu peut même utiliser la barre de financement intégrable de @Paidge pour financer la caisse qui servira a payer les bug bounty :smiley:

Je crois mieux comprendre : si au moins une source contient une condition non gérée, alors Cesium refuse toutes les sources de ce compte ?

Si c’est ça le comportement, alors oui c’est extrêmement plus gênant…

@paidge, tu as du temps pour un nouveau projet, genre debug Cesium ? :wink:

Moi qui croyais être clair :sweat_smile:

Oui, c’est ça. :+1:

Toutes les sources ne sont pas nécessairement bloquées. D’après mes observations, je suppose que :

  • les sources DU ne sont pas bloquées
  • si la source bloquante est la plus petite du compte, alors toutes les autres sont bloquées sur Cesium.
1 Like

Je ne suis pas compétent malheureusement :confused: Et puis après 3 semaines de développement de la barre de financement sur mon temps de travail, je vais ptet passer à faire ce pour quoi je suis payé ^^

3 Likes

Je pense qu’il faut chercher ici :

et ici :

Bon, vu qu’il n’y a pas de correction de bug, je vais le lancer moi-même, ce financement participatif / bug bounty. Je prévois plusieurs paliers :

400 DU : correction minimale du bug.
700 DU : dépense des sources composées avec conditions CSV et CLTV valides. Vérification que les sources XHX ne reproduisent pas ce blocage.
1500 DU : envoi de tx avec conditions composées et déblocage de conditions XHX (nécessité une modification de l’interface Cesium).

Ce serait en même temps un appel à financement et une demande de contribution. La somme récoltée serait reversée à læ dev qui aura fait la contribution en premier.

Est-il envisageable, dans la mesure où il s’ agit d’un bug critique, que la caisse des devs abonde à un tel financement?

2 Likes

Je pense qu’il faut pas faire trop de choses à la fois. Et que la première contribution est suffisamment intéressante. Pas sûr que ça soit un souhait d’implémenter la gestion des autres conditions alors qu’un Césium 2 est en développement.

On en a discuté dans ce post.

2 Likes

Financement lancé sur https://g1pourboire.fr/correction-bug-cesium.html !

Pour participer :
GcjRNKNjcGmMdcGjki1DVo5YDrXcRHPHLGBMKYVoZrV8

Le financement participatif vise 700 DU Ğ1. Parmi ces 700 :

  • 400 sont destinés à la dev, ou au dev, qui corrigera le bug. Ils seront versés après que le correctif ait été mergé.
  • 100 me sont destinés, pour la découverte du bug, l’insistance auprès des devs Cesium et l’animation de ce financement.
  • 100 sont destinés au développeur de Cesium qui relira le code et publiera une version officielle testée de Cesium
  • 50 sont un bonus pour læ dev, si la correction de bug est faite avant le 21 décembre 2019 à minuit.
  • 50 sont un bonus pour le développeur Cesium, si la publication de la version officielle de Cesium a lieu dans les 2 semaines qui suivent la correction de bug.
  • Si les bonus ne sont pas utilisés, ils financeront les noeuds et le développement logiciel de Duniter.

Les devs qui souhaitent corriger ce bug sont invités à se faire connaître sur le forum technique. Si le financement participatif n’est pas atteint à publication du correctif, un premier paiement aura lieu. Le deuxième paiement aura lieu lorsque le financement aura été rempli. Si un.e dev souhaite corriger ce bug, mais trouve le prix inadapté, qu’iel le signale, je choisirai en fonction des différentes offres proposées.

edit - selon ce que j’ai lu, @kimamila peut demander à verser 3*100=300DU depuis la caisse des devs.

3 Likes

Sur quel noeud G1-test as tu testé ?
Je ne reproduis pas

1 Like

Sur ts.gt.librelois.fr. Peut-être gtest.jytou.fr, vu que le noeud d’elois a cessé de répondre à un moment.

J’avais mis une limite de temps aujourd’hui dépassée. Je relance un petit blocage ce soir, dès que je rallume mon ordi sous Debian GNU.

Pour être tout à fait précis, les conditions étaient :

(SIG (recipient) && CSV(5 jours)) || SIG(sender)

1 Like

ok, la correction est faite dans la v1.4.11 tout fraiche !

6 Likes

Paiement fait après un test de la v1.5.2 concernant ce bug et celui concernant les comptes avec source unique relevé sur la v1.4.11.

Tout le financement n’est pas encore atteint.

silkaj -p g1.librelois.fr:443 tx --output 38MEAZN68Pz1DTvT3tqgxx4yQP6snJCQhPqEFxbDk4aE:CmFKubyqbmJWbhyH2eEPVSSs4H4NeXGDfrETzEnRFtPd:EUt3FqkmpUg8UdyrB2dGXtZoTo7GRXadEkHagL2q2AKb --amount 3989.35:725.34:362.67 
Please enter your Scrypt Salt (Secret identifier): 
Please enter your Scrypt password (masked): 
╒════════════════════════════════╤══════════════════════════════════════════════╕
│ pubkey’s balance before tx     │ 5077.36 Ğ1                                   │
├────────────────────────────────┼──────────────────────────────────────────────┤
│ total amount (unit | relative) │ 5077.36 Ğ1  ||  502.2117 UD                  │
├────────────────────────────────┼──────────────────────────────────────────────┤
│ pubkey’s balance after tx      │ 0.0 Ğ1                                       │
├────────────────────────────────┼──────────────────────────────────────────────┤
│ from (pubkey)                  │ GcjRNKNjcGmMdcGjki1DVo5YDrXcRHPHLGBMKYVoZrV8 │
├────────────────────────────────┼──────────────────────────────────────────────┤
│ to (pubkey)                    │ 38MEAZN68Pz1DTvT3tqgxx4yQP6snJCQhPqEFxbDk4aE │
├────────────────────────────────┼──────────────────────────────────────────────┤
│ to (id)                        │ BenoitLavenier                               │
├────────────────────────────────┼──────────────────────────────────────────────┤
│ amount (unit | relative)       │ 3989.35 Ğ1  ||  394.5945 UD                  │
├────────────────────────────────┼──────────────────────────────────────────────┤
│ to (pubkey)                    │ CmFKubyqbmJWbhyH2eEPVSSs4H4NeXGDfrETzEnRFtPd │
├────────────────────────────────┼──────────────────────────────────────────────┤
│ to (id)                        │ Matograine                                   │
├────────────────────────────────┼──────────────────────────────────────────────┤
│ amount (unit | relative)       │ 725.34 Ğ1  ||  71.7448 UD                    │
├────────────────────────────────┼──────────────────────────────────────────────┤
│ to (pubkey)                    │ EUt3FqkmpUg8UdyrB2dGXtZoTo7GRXadEkHagL2q2AKb │
├────────────────────────────────┼──────────────────────────────────────────────┤
│ amount (unit | relative)       │ 362.67 Ğ1  ||  35.8724 UD                    │
├────────────────────────────────┼──────────────────────────────────────────────┤
│ comment                        │                                              │
╘════════════════════════════════╧══════════════════════════════════════════════╛
Do you confirm sending this transaction? [yes/no]: yes
Generate Transaction:
   - From:    GcjRNKNjcGmMdcGjki1DVo5YDrXcRHPHLGBMKYVoZrV8
   - To:      38MEAZN68Pz1DTvT3tqgxx4yQP6snJCQhPqEFxbDk4aE 
   - Amount:  3989.35
   - To:      CmFKubyqbmJWbhyH2eEPVSSs4H4NeXGDfrETzEnRFtPd 
   - Amount:  725.34
   - To:      EUt3FqkmpUg8UdyrB2dGXtZoTo7GRXadEkHagL2q2AKb 
   - Amount:  362.67
Transaction successfully sent.
3 Likes