sdk_common/doc/Silent-Payments-Specs.md

Silent Payments - Specifications

1. Autheurs, validations, dates, versions, changement and historique

Cf. Git SDK COMMON

2. Table des matières

• 1. Autheurs, validations, dates, versions, changement and historique
• 2. Table des matières
• 3. Objectif
• 4. Portée
• 5. Documents de référence
• 6. Fonction
• 7. Structure des outputs
• 8. Envoi de la transaction SP
• 9. En réception les transactions silent Payments SP sont relayées par les relais en temps réel

3. Objectif

4. Portée

5. Documents de référence

Voir _Doc_references.md.

6.  Fonction

La transaction SP à plusieurs objectifs :

1. Permettre l'horodatage de l'empreinte des Prd sur la side chain.
2. Permettre le partage de la keyConfidential pour les Prd afin de déchiffrer les données confidentielles, sur d'autres relais que ceux qui ont reçu le Prd.

La clé KeyConfidential d'unetransaction SP est utilisée pour chiffrer les Prd.Cette clé est échangée avec le destinataire via un Diffie-Hellman (cf. Specs-Security.md) dans la transaction.

Cette information est parrallèle aux Prd et permet une meilleur sécurité et confidentialité des échanges.

Latransaction SP a aussi une fonction d'horodate et de preuve de publication des Prd donc de la validation des données des Pcd.Les outputs de latransaction SP contiennent les empreintes cryptographiques des Envelope et Prd et des Pcd.Ainsi l'infrastructure blockchain de signet de 4NK permet de vérifier l'intégrité des flux, leur ordre de référence (horodatage) et leur preuve de publication.

Les PrdConfirm qui sont des accusés automatiques de réception des Prd sont aussi associés à une transaction Silent Payments SP, ce qui permet d'ajouter les preuves de réception des demandes et des validations (ou non).

Il y a une transactions SP pour tous les types de Prd.

7.  Structure des outputs

Une fois le Prd finalisé, une transaction SP est réalisée, dans cette transaction plusieurs hashs sont ajoutés sur un outputs aux index suivants:

0. L'output 0 est toujours un paiment au destinataire
1. L'output 1 c'est toujours l'op_return avec un tableau de hashs en clair selon un tableau de hashs en JSON avec les index suivants : 1.1. Le hash de l'Envelope 1.2. Le hash du Prd 1.3. Le hash du process 1.4. Le hash de la valeur de la signature (attribut sig_value du Prd) 1.5. Le hash de item_name de Item concerné (le cas échéant) 1.6. Le hash du Prd d'origine associé au Prd (le cas échéant) 1.7. Le hash du Pcd d'origine associé au Prd (le cas échéant) 1.8. Le hash du Pcd de référence associé au Prd (le cas échéant) 1.9. Le hash d'un Amount de paiement (le cas échéant) 1.10. Le hash d'un Amountde dépôt (le cas échéant) 1.11. Un hash d'un engagement externe ou d'un Number (le cas échéant)

Pour des raison de confidentialité, le Role associé à item_name du Prd peut définir (option) un salt pour la génération des hashs dans l'attribut sp_output_salt_enc.

8. Envoi de la transaction SP

La transaction est envoyée dans le Envelope sur les relais, et aux utilisateurs pouvant relayer les transactions.

9.  En réception les transactions silent Payments SP sont relayées par les relais en temps réel

Le relais récupère les transactions depuis l'interface ZMQ du noeud Bitcoin : https://github.com/bitcoin/bitcoin/blob/master/doc/zmq.md. Puis il ajoute le tweak data de la transaction Silent Payments, puis il envoie la transaction à tous les connectés.

Puis le relais relaient les transactions dans le format suivant :

• raw_tx: La transaction en hexadécimal
• pubkey: La clé publique du Member qui a envoyé la transaction

Le même procédé existe pour les blocs :

• raw_block: Le bloc en hexadécimal