On pourrait comme le dit @vit définir une regex du style [-A-Z]+:[-A-Z]+:[-0-9a-f]+ afin de détecter automatiquement ces cas précis et ne pas chiffrer uniquement dans ce cas.
Ne pas avoir de cases à cocher à deux avantage :
Réunion lourde en contenu, plein de choses à retenir, et comme dis plus haut, il y a bien un temps de réflexion aussi après 
Du coup oui, forcément, je préfère reposer les questions si j’ai un doute 
Là ce qui me gênait c’est qu’effectivement ça n’empêche que les envois de données non-malveillants, mais en réalité sans toucher au protocole, pas de miracle. Ça permet au moins de réduire les risques
On finira par y toucher. Mais faut d’abord une API GVA complète et en prod pour que wotwizard migre dessus.
À long terme, je souhaite toujours la suppression pure et simple du champ commentaire en blockchain, mais j’aimerais attendre qu’on ait une alternative, comme par exemple un DHT public géré par les nœuds Duniter.
Just learning of « encryption of tx comments » today, and sharing thoughts.
I like the idea that personal comments are not visible outside the parties involved in a transaction. good stuff.
I assume that this only works in standard transactions, where the sender/receiver are identifiable because sender is the only issuer and might be an output (if getting change), and there is only one other output which is the receiver. ???
In other words… that comments could not be encrypted/decrypted by all parties when multiple issuers are sending or when multiple outputs (other than issuer’s change) are receivers ???
Im thinking of mixes from multiple parties, payment mixes, and even single-sender transactions from HD wallets where, in the future, we may religiously use different pubkeys from our HD wallets when receiving payments or even when sending change back to ourselves.
Last assumption to clarify… that this is NOT a DUBP change because nothing about the transaction document structure is changing, rather it’s a wallet-implementation change (or whatever software is preparing the transaction before signing). (I seem to recall a list of characters acceptable in comments, as well as a comment length… but if the ciphertext encoding doesnt break the comment-alphabet and still fits… its not a structural change and feels safe to me).
Spencer971
p.s. I’ve been distracted and away from this forum way too long. Great job devs on how far ideas are moving forward! 
Yes, at first we will encrypt comments only for transactions with a single sender and a single receiver. That is 99% of the transactions.
This is not a problem, as long as each party is able to know which is the public key of the other, which is the case because the sender knows which key he sends the funds to and the receiver knows which key belongs to him
The mixing of transactions is usually done between 2 accounts owned by the same owner, so no need to comment.
Absolutely, we not change the DUBP protocol
I have already checked all these points, it is indicated in the spec : rfc/0017_transaction_comment_encryption.md · tx_comment_encrypt · documents / RFCs · GitLab