On passerait ainsi de commentaire publics en chaîne de bloc à des commentaire privés mais toujours écrit sur la chaîne qui reste publique. OK. Malin.
Est-ce qu’on pourra choisir si on veut un commentaire public ou privé ?
L’idée c’est que non puisque cette proposition est une réponse aux abus récents constatés dans les commentaires publics.
1 Like
Est-ce que cela ne risque-t-il pas d’être handicapant dans la recherche de double compte ou autre compte multiple ?
Ça n’a pas à l’être, les commentaires de transaction sont une donnée à caractères personnels, ils n’ont pas à être publics. Il convient de séparer les problèmes.
1 Like
Si on suppose qu’un attaquant est doué, non, puisqu’il se sera débrouillé pour ne pas être démasqué à cause de ses commentaires (par exemple en les laissant vides).
Et pour la vie privée, il faut qu’il puissent être privés.
1 Like
L’idée serait que les commentaires de transactions ne serait plus lisible par tout le monde ? J’adhère !
mais par qui seraient-ils lisible alors ?
Par l’emetteurice et læ destinataire.
3 Likes
Du coup, un bloc serait refusé s’il contient un commentaire non-chiffré ?
En jetant un oeil rapide sur la RFC, je ne vois pas d’indications mentionnant cela, ni même comment faire.
Ne serait-il pas possible de forger un message respectant le prefix, message_type, nonce et padding, puis de mettre des bytes dans le message, qui, une fois encodés en b64 ou 85 produisent un texte lisible par un humain ?
Certes, toute tentative de déchiffrement serait infructueuse, mais il y aurait bien une donnée lisible dans la blockchain qui n’est potentiellement pas acceptable
Non le forçage sera uniquement coté client pour le moment, car sinon cela impliquera un changement de protocole, et comme on a dit dans la réunion mensuelle d’hier soir où tu étais présent on ne veut pas pousser de changement de protocole tant que cela casserait wot zizard
@Luke la solution proposée ici est de court-terme, à moyen-long terme on supprimera le champ commentaire et les commentaires seront stockés hors-blockchain mais pour ça il faut d’abord mettre en place la DHT publique qui permettra de stocker ces commentaires, j’ai l’impression de répéter tout ce que j’ai expliqué hier soir à l’oral !
1 Like
il y aura toujours cette possibilité dans la condition XHX avec un encodage hexadecimal (et même, en étant astucieux, avec un enchaînement de conditions CLTV…). Le fait que des données arbitraires soient enregistrées en BC est à ma connaissance impossible à interdire. En revanche, on peut éviter que certaines données soient directement disponibles en clair.
Je n’y penses que maintenant, mais qu’il faut garder la possibilité de mettre une référence qui est un hash, pour un suivi quelconque.
Par exemple Gannonce et Gchange s’en servent pour incrémenter les compteurs des financements participatif.
2 Likes
Ce sera le cas puisse qu’on ne change pas le protocole 
1 Like
Mais si Cesium propose toujours d’écrire le commentaire en clair, alors ça ne permet pas d’empêcher ce qu’on veut empêcher…
Et en fait, si quelqu’un veut toujours écrire des commentaires en clair, il n’aura qu’à ne pas mettre à jour Cesium, ce qui est à la portée de tout le monde. Donc est-ce vraiment utile même à court terme ?
@kimamila était présent à la réunion hier soir et était impliqué dans la discussion qui à fait émerger cette solution court-terme, c’est lui qui demande qu’on fasse ça pour ne pas s’embêter à devoir stocker les commentaires hors-blockchain, donc logiquement il ne permettra plus les commentaires en clair 
Avant de décider de la solution, il faut réfléchir à tous les impacts et ne pas se précipiter. On ne peut pas penser à tout lors d’une réunion. Il faut du temps.
S’il nous faut toujours des commentaires non chiffrés, par exemple pour le suivi, alors les clients auront besoin d’une fonction pour cela.
Je vous plusieurs solutions :
- détecter certains patterns, et ne pas les chiffrer;
- mettre une checkbox « chiffrement (recommandé) » coché par défaut ;
-ou alors les deux : si détection de pattern alors on décoche la case.
La détection de pattern pourrait aussi permettre de coller directement un message déjà chiffré (détection via la premier bit) pour éviter de le re-chiffrer.
Vos avis ?
Pas de checkbox à mon avis, ça complique.
C’est au code du client de détecter si le commentaire respecte un pattern bien limité ou non.
Peut tu préciser le cas d’usage, pour le suivi de quoi exactement ? En quoi un commentaire chiffré empêche ce suivi ?
Puisque le destinataire peut le déchiffrer, rien n’empêche le programme de suivi utilisé par le destinataire de déchiffrer tout le nécessaire, je ne comprends pas où est le problème.
Surtout ça ne nous couvre pas contre le problème originel que l’on doit résoudre : empêcher l’utilisateur de publier un texte libre et public dans la blockchain.
C’est pas les systèmes comme gannonce qui font ça, non ?
Exemple : https://gannonce.duniter.org/#/announce/e5d2df8a-d6f7-48c5-8239-15fee5cf9e4d
Via Sakia
Envoyer de la monnaie :
- à la clé publique 7zP9B4UwKnEWtahTQzeRcFha4kSyKLZ7VsVXN9Cx92ea
- avec commentaire GANNONCE:CROWDF:e5d2df8a-d6f7-48c5-8239-15fee5cf9e4d pour le suivi du crowdfunding
Visiblement c’est un client tiers qui check le commentaire et non le destinataire, donc il n’aura pas de possibilité de décoder le commentaire si celui-ci est chiffré.
J’aime bien l’idée de laisser la possibilité de chiffrer ou non le commentaire bien que ça ne réponde pas à “empêcher l’utilisateur de publier un texte libre et public dans la blockchain”
1 Like