# Silent Payments - Specifications ## 1. Autheurs, validations, dates, versions, changement and historique Cf. [Git SDK COMMON](https://git.4nk.com/4nk/sdk_common/doc) ## 2. Table des matières * 1. [Autheurs, validations, dates, versions, changement and historique](#Autheursvalidationsdatesversionschangementandhistorique) * 2. [Table des matières](#Tabledesmatires) * 3. [Objectif](#Objectif) * 4. [Portée](#Porte) * 5. [Documents de référence](#Documentsderfrence) * 6. [ Fonction](#Fonction) * 7. [ Structure des outputs](#Structuredesoutputs) * 8. [Envoi de la transaction SP](#EnvoidelatransactionSP) * 9. [ En réception les transactions silent Payments SP sont relayées par les relais en temps réel](#EnrceptionlestransactionssilentPaymentsSPsontrelayesparlesrelaisentempsrel) ## 3. Objectif ## 4. Portée ## 5. Documents de référence Voir [_Doc_references.md](_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'une`transaction SP` est utilisée pour chiffrer les `Prd`.Cette clé est échangée avec le destinataire via un Diffie-Hellman (cf. [Specs-Security.md](Specs-Security.md)) dans la transaction. Cette information est parrallèle aux `Prd` et permet une meilleur sécurité et confidentialité des échanges. La`transaction 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 la`transaction 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 `Amount`de 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 : . 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