Eviter les transactions erronées techniquement !


#1

J’ai pensé à une solution qui me paraît simple et efficace pour éviter les envois de transactions sur des clés erronées. En effet si on y prend garde, un mauvais copié / collé de clé, une erreur, une mauvaise manip qui fausse un caractère, et la clé cible ne sera pas la bonne, la somme perdue…

Idem si le réceptionnaire est correct, mais a oublié ses clés privées…

La solution consiste à ne valider la réception de la transaction que si le réceptionnaire la valide par signature, assurant ainsi l’envoyeur que le réceptionnaire maîtrise bien sa clé et évite donc les deux cas sus-cités.

Je suppose que la création d’un document spécifique de type “transaction sécurisée” qui demande la signature double de l’envoyeur + du destinataire devrait permettre cette fonctionnalité technique qui à mon avis peut éviter bien des déconvenues !


#2

La solution serait surtout de généraliser les adresses (hash de clé publique avec un CRC pour s’assurer qu’il n’y ait pas d’erreur de copier coller).

Cf [Protocole] Paiement vers une adresse


#3

Non ça ne résoud pas le problème de s’assurer que les clés privées sont bien contrôlées par le réceptionnaire. Ca ne voit qu’un bout de la lorgnette !


#4

Pas faux :slight_smile:

Il faudrait mettre en conditions de déverouillage des output :

  • Les outputs vers le destinataire : La signature de l’envoyeur et la signature du destinataire
  • Les outputs de retour à l’envoyeur : La signature de l’envoyeur (permet de récupérer les fonds)

#5

Pour le premier problème, à savoir, s’assurer d’émettre sur la bonne clée, silkaj implémente une vérification de somme de contrôle de la clé publique :

 - tx/transaction: Send transaction    
     - authentication: see below section    
     - amount:    
         --amountUD=<relative value> | --amount=<quantitative value>    
         [--allSources]     
     --output=<public key>[!checksum]:[<public key>[!checksum]]

#6

Il existe déjà dans le protocole actuel un mécanisme de récupération des fonds si le destinataire ne les récupère pas dans un temps donné.

Mais pour l’instant aucun client ne permet son exploitation.

J’avais développé ce mécanisme pour les besoins de transactions de change interblockchains. Il est également connu sous le nom de Atomic Swap Protocol.


#7

Le thème des RML13 étant “coeur de Ğ1” concentré à 100% sur DUP, Duniter, Juniter, DURS, SIlkaj, à l’exclusion de toute agitation externe, la présentation de ce point du protocole doit en faire en partie ! Il devient crucial avec le développement de l’utilisation et des montants d’échange de Ğ1 de développer la connaissance et l’extension de ces développements de sécurité dans le protocole.


#8

Cesium assure également de la vérification du checksum. Exemple :

Il faudrait que les fonctions d’affichage de la clé publique ajoute le checksum (pour commencer), pour que les copier/coller l’utilise.

J’ai commencé à travailler sur ce point, notamment pour l’affichage. Mais c’est resté en chantier…

Reste un gros travail sur la récupération et l’utilisation de ces outputs avec conditions.


#9

Oui, il est temps de fiabiliser au maximum les paiements, tant que la communauté est encore petite.