5.2 KiB
Silent Payments - Specifications
1. Autheurs, validations, dates, versions, changement and historique
Cf. Git SDK COMMON
2. Table des matières
3. Objectif
4. Portée
5. Documents de référence
Voir _Doc_references.md.
6. Fonction
La transaction SP à plusieurs objectifs :
- Permettre l'horodatage de l'empreinte des
Prdsur la side chain (PrdKeyMessagesans message confidentiel). - Permettre le partage de la
keyConfidentialpour lesPrdafin de déchiffrer les données confidentielles, sur d'autres relais que ceux qui ont reçu lePrd.
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 messages 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:
- L'output 0 est toujours un paiment au destinataire
- 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 du message de type
Messagecorrespondant 1.2. Le hash duPrd1.3. Le hash du process 1.4. Le hash de la valeur de la signature (attributsig_valuedu Prd) 1.5. Le hash de l'item_namede l'Itemconcerné (le cas échéant) 1.6. Le hash duPrdd'origine associé auPrd(le cas échéant) 1.7. Le hash duPcdd'origine associé auPrd(le cas échéant) 1.8. Le hash duPcdde référence associé auPrd(le cas échéant) 1.9. Le hash d'unAmountde paiement (le cas échéant) 1.10. Le hash d'unAmountde dépôt (le cas échéant) 1.11. Un hash d'un engagement externe ou d'unNumber(le cas échéant)
Pour des raison de confidentialité, le Role associé à l'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
Afin d'améliorer la rélisience du broadcast des transactions, la transaction est envoyée à la fois :
- Dans un
PrdMessageà un membre du rôlememberduItemProcessconcerné et - Dans le
MessageduPrdMessagesur les relais
8.1. Dans un PrdMessage
Dans l'attribut raw_transaction_list du PrdMessage associé à la transaction SP.
La transaction sera broadcastée par les noeuds de signet du membre du Role member du ItemProcess concerné qui a reçu ce message, il devra alors avoir un noeud de signet pour le broadcast.
8.2. Dans un Message du PrdMessage
Dans l'attribut raw_transaction_list du Message associé à la transaction SP.
La transaction sera broadcastée par les noeuds de signet des relais.
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 membre qui a envoyé la transaction
Le même procédé existe pour les blocs :
- raw_block: Le bloc en hexadécimal