Protocoles de transactions sécurisées

Bonjour,

On a pas mal de discussions concernant la sécurité des transactions, beaucoup de choses se mélangent…

Je souhaite proposer trois façons de faire des transactions sécurisées, avec différents niveaux répondant à différents besoins. Ces protocoles demandent des modifications des clients et devraient être accessibles de façon optionnelle.

1- Récupérer la monnaie envoyée à une clef pub non utilisée (faute de frappe)

Si le client de l’émetteur détecte que la clef destinataire n’a reçu émis aucune transaction, il envoie une tx avec condition de lock :

(SIG(receiver) || (SIG(sender) && CSV(1_week)))

Le client du destinataire, voyant cette condition de lock particulière, propose au destinataire de réceptionner cette transaction en envoyant la monnaie à lui-même. Sans quoi, l’émetteur peut récupérer la monnaie après une semaine (le client devrait le lui proposer et ne pas le faire automatiquement).

Ce mode de transaction ne protège pas du fishing.

2- S’assurer que la somme a été envoyée à la bonne personne

On est dans le cas d’envoi de grosses sommes, et on veut éviter le fishing.

L’émetteur envoie la tx avec conditions de lock :

((SIG(receiver) && XHX(hash)) || (SIG(sender) && CSV(1_week)))

Ainsi, après avoir envoyé la transaction, on transmet le mot de passe à la bonne personne par un biais indépendant de la clef pub (pas par message Cesium ou chiffrement par Duniterpy), et celle-ci peut valider la réception.

Si l’émetteur a été victime de fishing, il peut récupérer la monnaie après 1 semaine.

3- Transactions sujettes à conflit (immobilier, envois à distance, etc.)

Les parties vont désigner un tiers de confiance (huissier) et vont pouvoir débloquer les fonds par eux-mêmes si tout va bien, sinon l’huissier pourra débloquer la situation

l’émetteur envoie une transaction (celle-ci peut contenir en commentaire le hash du contrat passé par les trois parties) avec conditions de lock :

((SIG(sender) && SIG(receiver)) || (SIG(sender) && SIG(tier)) || (SIG(receiver) && SIG(tier)))

Si tout se passe bien, sender et receiver peuvent co-signer un doc de transaction validant l’envoi au receiver seul.

Si tout ne se passe pas bien, l’huissier peut arbitrer et débloquer les fonds avec l’accord d’un des protagonistes, suivant les termes de l’accord passé.

Pour que le multisig soit implémenté de façon sécurisé, il faut que les clients puissent exporter, importer, signer des fichiers de transaction partiellement signés, et éventuellement se les transmettre, ou de préférence utiliser une application tierce (courriel, texto) pour se les transmettre.

8 Likes

Je vais commencer à travailler sur l’implémentation de ces propositions dans Sakia.

J’ai fait un schéma pour comprendre le système Atomic Swap. Je le partage ici :

Duniter Atomic Swap

Dites moi si c’est clair.

3 Likes

Le développement du support des conditions de verrouillage proposées ici avance bien dans Sakia.

Dans l’interface :

  • On peut maintenant choisir de faire une transaction simple, ou avec les conditions citées en 1, via un simple sélecteur.

Dans le code :

  • Pour faire une transaction Sakia va maintenant accepter les sources à conditions complexes comme celle proposée en 1. La fonction qui évalue la condition supporte TOUS les types de conditions (y compris les transactions nécessaires à un échange en Atomic Swap).

Reste à faire :

  • Grâce aux conditions de dépense de Duniter, on peut avoir un état quantique d’une source. Elle peut être dépensée par la signature de Alice ou Bob. Afficher dans Sakia les dépenses que l’on peut récupérer pour s’en servir comme source dans la création d’une nouvelle transaction.
  • Utiliser comme source la transaction sélectionnée dans l’historique, pour le formulaire de transaction.

Stay tuned…

4 Likes