diff --git a/doc/Messages-SP-Specs.md b/doc/Messages-SP-Specs.md
index e400b94..5f417bf 100644
--- a/doc/Messages-SP-Specs.md
+++ b/doc/Messages-SP-Specs.md
@@ -2,46 +2,47 @@
 * 1. [Objectif](#Objectif)
 * 2. [Portée](#Porte)
 * 3. [3. Documents de référence](#Documentsderfrence)
-* 4. [Variable `SharedPeerList` du SDK (Wasm)](#VariableSharedPeerListduSDKWasm)
-* 5. [Structure du stockage en cache](#Structuredustockageencache)
- 	* 5.1. [Relais](#Relais)
- 	* 5.2. [5. Process](#Process)
- 	* 5.3. [Liste des hashs des messages reçus](#Listedeshashsdesmessagesreus)
- 	* 5.4. [Liste des sockets ouverts](#Listedessocketsouverts)
-* 6. [Caractéristiques générales des messages de type `Message` et de type `MessageConnect`](#CaractristiquesgnralesdesmessagesdetypeMessageetdetypeMessageConnect)
- 	* 6.1. [SharedPeerList](#SharedPeerList)
- 	* 6.2. [SharedProcessList](#SharedProcessList)
- 	* 6.3. [Taille des données](#Tailledesdonnes)
- 	* 6.4. [Preuve de travail](#Preuvedetravail)
- 	* 6.5. [Adresse SP de faucet](#AdresseSPdefaucet)
-* 7. [Traitments par les clients](#Traitmentsparlesclients)
- 	* 7.1. [Connexion d'un client à sa liste relais via les messages de type `MessageConnect`](#ConnexiondunclientsalisterelaisvialesmessagesdetypeMessageConnect)
-  		* 7.1.1. [Récupération et choix des relais](#Rcuprationetchoixdesrelais)
-  		* 7.1.2. [Envoi du message de type `MessageConnect` à chaque relais](#EnvoidumessagedetypeMessageConnectchaquerelais)
- 	* 7.2. [Envoi de PCD sur les relais via les messages de type `Message`](#EnvoidePCDsurlesrelaisvialesmessagesdetypeMessage)
- 	* 7.3. [Envoi de PRD sur les relais via les messages de type `Message`](#EnvoidePRDsurlesrelaisvialesmessagesdetypeMessage)
- 	* 7.4. [Traitement des messages de type `Message` par les clients](#TraitementdesmessagesdetypeMessageparlesclients)
-* 8. [Traitements par les relais](#Traitementsparlesrelais)
- 	* 8.1. [Traitement des messages de type `MessageConnect` par les relais](#TraitementdesmessagesdetypeMessageConnectparlesrelais)
- 	* 8.2. [Connexion au réseau de relais via les messages de type `MessageConnect` par les relais](#ConnexionaurseauderelaisvialesmessagesdetypeMessageConnectparlesrelais)
-* 9. [Traitement des messages de type `Message` par les relais](#TraitementdesmessagesdetypeMessageparlesrelais)
- 	* 9.1. [Broadcast des messages de type `Message` vers les relais](#BroadcastdesmessagesdetypeMessageverslesrelais)
- 	* 9.2. [Broadcast des messages de type `Message` vers les clients connectés](#BroadcastdesmessagesdetypeMessageverslesclientsconnects)
-* 10. [Connexions aux réseaux de noeuds de bitcoin de réseaux side chain ou mainnet](#Connexionsauxrseauxdenoeudsdebitcoinderseauxsidechainoumainnet)
- 	* 10.1. [Protocole de Découverte des Pairs](#ProtocoledeDcouvertedesPairs)
- 	* 10.2. [Protocole de Transmission des Transactions](#ProtocoledeTransmissiondesTransactions)
- 	* 10.3. [Protocole de Partage des Blocs](#ProtocoledePartagedesBlocs)
- 	* 10.4. [Validation et relais](#Validationetrelais)
- 	* 10.5. [Gestion des Forks](#GestiondesForks)
- 	* 10.6. [Connexion au réseau de nodes de side chain](#Connexionaurseaudenodesdesidechain)
-  		* 10.6.1. [Clients](#Clients)
-  		* 10.6.2. [Relais](#Relais-1)
- 	* 10.7. [Connexion au réseau de nodes de layer 1](#Connexionaurseaudenodesdelayer1)
- 	* 10.8. [Horodatage et ancrage des PRD via les transactions Silent Payment (SP)](#HorodatageetancragedesPRDvialestransactionsSilentPaymentSP)
-* 11. [Transactions mainnet Bitcoin](#TransactionsmainnetBitcoin)
- 	* 11.1. [Horodatage et ancrage des blocs de la side chain sur Bitcoin](#HorodatageetancragedesblocsdelasidechainsurBitcoin)
- 	* 11.2. [Remboursement des frais d'horodatage et ancrage des blocs de la side chain sur Bitcoin](#RemboursementdesfraisdhorodatageetancragedesblocsdelasidechainsurBitcoin)
+* 4. [## 4. Variable `SharedPeerList` du SDK (Wasm)](#4.VariableSharedPeerListduSDKWasm)
+* 5. [5. Structure du stockage en cache](#Structuredustockageencache)
+  * 5.1. [5.1. Relais](#Relais)
+  * 5.2. [5.2. Process](#Process)
+  * 5.3. [5.3. Liste des hashs des messages reçus](#Listedeshashsdesmessagesreus)
+  * 5.4. [5.4. Liste des sockets ouverts](#Listedessocketsouverts)
+* 6. [6. Caractéristiques générales des messages de type `Message` et de type `MessageConnect`](#CaractristiquesgnralesdesmessagesdetypeMessageetdetypeMessageConnect)
+  * 6.1. [6.1. SharedPeerList](#SharedPeerList)
+  * 6.2. [6.2. SharedProcessList](#SharedProcessList)
+  * 6.3. [6.3. Taille des données](#Tailledesdonnes)
+  * 6.4. [6.4. Preuve de travail](#Preuvedetravail)
+  * 6.5. [6.5. Adresse SP de faucet](#AdresseSPdefaucet)
+* 7. [7. Traitements par les clients](#Traitementsparlesclients)
+  * 7.1. [7.1. Connexion d'un client à sa liste relais via les messages de type `MessageConnect`](#ConnexiondunclientsalisterelaisvialesmessagesdetypeMessageConnect)
+    * 7.1.1. [7.1.1. Récupération et choix des relais](#Rcuprationetchoixdesrelais)
+    * 7.1.2. [7.1.2. Envoi du message de type `MessageConnect` à chaque relais](#EnvoidumessagedetypeMessageConnectchaquerelais)
+  * 7.2. [7.2. Envoi de PCD sur les relais via les messages de type `Message`](#EnvoidePCDsurlesrelaisvialesmessagesdetypeMessage)
+  * 7.3. [7.3. Envoi de PRD sur les relais via les messages de type `Message`](#EnvoidePRDsurlesrelaisvialesmessagesdetypeMessage)
+  * 7.4. [7.4. Traitement des messages de type `Message` par les clients](#TraitementdesmessagesdetypeMessageparlesclients)
+* 8. [8. Traitements par les relais](#Traitementsparlesrelais)
+  * 8.1. [8.1. Traitement des messages de type `MessageConnect` par les relais](#TraitementdesmessagesdetypeMessageConnectparlesrelais)
+  * 8.2. [8.2. Connexion au réseau de relais via les messages de type `MessageConnect` par les relais](#ConnexionaurseauderelaisvialesmessagesdetypeMessageConnectparlesrelais)
+* 9. [9. 9. Traitement des messages de type `Message` par les relais](#TraitementdesmessagesdetypeMessageparlesrelais)
+  * 9.1. [9.1. Broadcast des messages de type `Message` vers les relais](#BroadcastdesmessagesdetypeMessageverslesrelais)
+  * 9.2. [9.2. Broadcast des messages de type `Message` vers les clients connectés](#BroadcastdesmessagesdetypeMessageverslesclientsconnects)
+* 10. [10. Connexions aux réseaux de noeuds de bitcoin de réseaux side chain ou mainnet](#Connexionsauxrseauxdenoeudsdebitcoinderseauxsidechainoumainnet)
+  * 10.1. [10.1. Protocole de Découverte des Pairs](#ProtocoledeDcouvertedesPairs)
+  * 10.2. [10.2. Protocole de Transmission des Transactions](#ProtocoledeTransmissiondesTransactions)
+  * 10.3. [10.3. Protocole de Partage des Blocs](#ProtocoledePartagedesBlocs)
+  * 10.4. [10.4. Validation et relais](#Validationetrelais)
+  * 10.5. [10.5. Gestion des Forks](#GestiondesForks)
+  * 10.6. [10.6. Connexion au réseau de nœuds de side chain](#Connexionaurseaudenudsdesidechain)
+    * 10.6.1. [10.6.1. Clients](#Clients)
+    * 10.6.2. [10.6.2. Relais](#Relais-1)
+  * 10.7. [10.7. Connexion au réseau de nœuds de layer 1](#Connexionaurseaudenudsdelayer1)
+  * 10.8. [10.8. Horodatage et ancrage des PRD via les transactions Silent Payment (SP)](#HorodatageetancragedesPRDvialestransactionsSilentPaymentSP)
+* 11. [## 11. Transactions mainnet Bitcoin](#11.TransactionsmainnetBitcoin)
+  * 11.1. [11.1. Horodatage et ancrage des blocs de la side chain sur Bitcoin](#HorodatageetancragedesblocsdelasidechainsurBitcoin)
+  * 11.2. [11.2. Remboursement des frais d'horodatage et ancrage des blocs de la side chain sur Bitcoin](#RemboursementdesfraisdhorodatageetancragedesblocsdelasidechainsurBitcoin)
 * 12. [Exemples de Code](#ExemplesdeCode)
+* 13. [Markdown todo](#Markdowntodo)
 
 <!-- vscode-markdown-toc-config
 	numbering=true
@@ -57,136 +58,132 @@
 
 Voir [Doc_references.md](Doc_references.md).
 
-## 4. <a name='VariableSharedPeerListduSDKWasm'></a>Variable `SharedPeerList` du SDK (Wasm)
+## 4. <a name='4.VariableSharedPeerListduSDKWasm'></a>## 4. Variable `SharedPeerList` du SDK (Wasm)
 
 La variable `SharedPeerList` du SDK (Wasm) est une liste de relais partagée avec les relais, c'est la première liste disponible, en dur fournie par le relais sur lequel on est connecté.
 
-## 5. <a name='Structuredustockageencache'></a>Structure du stockage en cache
+## 5. <a name='Structuredustockageencache'></a>5. Structure du stockage en cache
 
-### 5.1. <a name='Relais'></a>  Relais
+### 5.1. <a name='Relais'></a>5.1. Relais
 
 Le cache est constitué de 2 parties :
 
 1. `public` :
-   1.1. Liste partagée des relais avec les relais (aggrée au fil des relais découverts par le partage des listes de relais dans les messages).
-   2.2. L'historique des pings des relais (timestamp, valeur du ping, relais concerné)
-   2.3. L'historique de message reçus ne satisfaisant pas à l'arbitrage (timestamp, hash du message, relais concerné).
-   2.4. L'historique de message envoyés sans retour d'une transaction Silent Payment (SP)
+   * Liste partagée des relais avec les relais (agrégée au fil des relais découverts par le partage des listes de relais dans les messages).
+   * L'historique des pings des relais (timestamp, valeur du ping, relais concerné).
+   * L'historique de message reçus ne satisfaisant pas à l'arbitrage (timestamp, hash du message, relais concerné).
+   * L'historique de message envoyés sans retour d'une transaction Silent Payment (SP).
 2. `private` :
-   2.1. Liste non partagée des relais (aggrégée à partir de relais communiqués de façon confidentielle).
-   2.2. L'historique des pings des relais (timestamp, valeur du ping, relais concerné)
-   2.3. L'historique de message reçus ne satisfaisant pas à l'arbitrage (timestamp, hash du message, relais concerné).
-   2.4. L'historique de message envoyés sans retour d'une transaction Silent Payment (SP)
+   * Liste non partagée des relais (agrégée à partir de relais communiqués de façon confidentielle).
+   * L'historique des pings des relais (timestamp, valeur du ping, relais concerné).
+   * L'historique de message reçus ne satisfaisant pas à l'arbitrage (timestamp, hash du message, relais concerné).
+   * L'historique de message envoyés sans retour d'une transaction Silent Payment (SP).
 
-Dans chaque partie, les relais sont stockés sous forme d'objets `SharedPeer` (décris dans [Specs-Datamodel.md](Specs-Datamodel.md)).
+Dans chaque partie, les relais sont stockés sous forme d'objets `SharedPeer` (décrits dans [Specs-Datamodel.md](Specs-Datamodel.md)).
 
-Les relais sont ainsi partagés sous forme d'objets `SharedPeer` (décris dans [Specs-Datamodel.md](Specs-Datamodel.md)).
-
-### 5.2. <a name='Process'></a>5. Process
+### 5.2. <a name='Process'></a>5.2. Process
 
 Le cache est constitué de 2 parties :
 
 1. `public` :
-   1.1. Liste partagée des process avec les relais (aggrée au fil des relais découverts par le partage des listes de process dans les messages).
-   1.2. Liste partagée des process complets reçues depuis les mises à jour des parties prenantes
+   * Liste partagée des process avec les relais (agrégée au fil des relais découverts par le partage des listes de process dans les messages).
+   * Liste partagée des process complets reçus depuis les mises à jour des parties prenantes.
 2. `private` :
-   2.1. Listenon partagée  des process (aggrégée à partir de process communiqués de façon confidentielle).
-   1.2. Liste non partagée des process complets reçues depuis les mises à jour des parties prenantes
+   * Liste non partagée des process (agrégée à partir de process communiqués de façon confidentielle).
+   * Liste non partagée des process complets reçus depuis les mises à jour des parties prenantes.
 
-Dans chaque partie, les process sont stockés sous forme d'objets `SharedProcess` (décris dans [Specs-Datamodel.md](Specs-Datamodel.md)).
+Dans chaque partie, les process sont stockés sous forme d'objets `SharedProcess` (décrits dans [Specs-Datamodel.md](Specs-Datamodel.md)).
 
-Les process sont ainsi partagés sous forme d'objets `SharedProcess` (décris dans [Specs-Datamodel.md](Specs-Datamodel.md)).
+### 5.3. <a name='Listedeshashsdesmessagesreus'></a>5.3. Liste des hashs des messages reçus
 
-### 5.3. <a name='Listedeshashsdesmessagesreus'></a>Liste des hashs des messages reçus
-
-Le cache contient une liste des hashs des messages de type `Message` et de type `MessageConnect` reçus, répartie en 3 parties :
+Le cache contient une liste des hashs des messages de type `Message` et de type `MessageConnect` reçus, répartie en plusieurs parties :
 
 * MessageHashList: Hashs des objets `Message`.
 * MessageConnectHashList: Hashs des objets `MessageConnect` (vide pour les clients).
 * MessageDataEncHashList: Hashs de la donnée encryptée dans les objets `Message`.
-* PCDHashList: Hashs des `PCD` une fois déchiffrés des objets Message `Message`, avec le hash du message correspondant  (vide pour les relais) et état actuel de la collecte des PRD correspondants.
+* PCDHashList: Hashs des `PCD` une fois déchiffrés des objets Message `Message`, avec le hash du message correspondant (vide pour les relais) et état actuel de la collecte des PRD correspondants.
 * PRDHashList: Hashs des `PRD` une fois déchiffrés des objets Message `Message`, avec le hash du message correspondant et l'id de la transaction Silent Payment (SP) correspondante (vide pour les relais).
 * TxFaucetIdList: Liste des transactions classiques du faucet.
 * TxSpIdList: Liste des transactions silent payment (SP) reçues.
 
-### 5.4. <a name='Listedessocketsouverts'></a>Liste des sockets ouverts
+### 5.4. <a name='Listedessocketsouverts'></a>5.4. Liste des sockets ouverts
 
 Le cache contient une liste des sockets ouverts, répartie en 2 parties :
 
-* SocketClientList : liste des sockets ouverts en tant que clients.
-* SocketServerList : liste des sockets ouverts par les clients.
+* SocketClientList: liste des sockets ouverts en tant que clients.
+* SocketServerList: liste des sockets ouverts parles clients.
 
-## 6. <a name='CaractristiquesgnralesdesmessagesdetypeMessageetdetypeMessageConnect'></a>Caractéristiques générales des messages de type `Message` et de type `MessageConnect`
+## 6. <a name='CaractristiquesgnralesdesmessagesdetypeMessageetdetypeMessageConnect'></a>6. Caractéristiques générales des messages de type `Message` et de type `MessageConnect`
 
-### 6.1. <a name='SharedPeerList'></a>SharedPeerList
+### 6.1. <a name='SharedPeerList'></a>6.1. SharedPeerList
 
 `SharedPeerList` est une liste de relais. Les relais et les clients partagent cette liste qu'ils complètent au fur et à mesure de leur découverte de relais.
 
-### 6.2. <a name='SharedProcessList'></a>SharedProcessList
+### 6.2. <a name='SharedProcessList'></a>6.2. SharedProcessList
 
 `SharedProcessList` est une liste de process. Les relais et les clients partagent cette liste qu'ils complètent au fur et à mesure de leur découverte de process.
 
-### 6.3. <a name='Tailledesdonnes'></a>Taille des données
+### 6.3. <a name='Tailledesdonnes'></a>6.3. Taille des données
 
-Les objets `SharedPeer` indiquent la taille maximale des données pour les messages de type `Message` et de type `MessageConnect` dans l'attribut des `data_max_size` du sous attribut `relay`. Les messages plus gros que cette taille sont rejetés.
+Les objets `SharedPeer` indiquent la taille maximale des données pour les messages de type `Message` et de type `MessageConnect` dans l'attribut `data_max_size` du sous attribut `relay`. Les messages plus gros que cette taille sont rejetés.
 
-### 6.4. <a name='Preuvedetravail'></a>Preuve de travail
+### 6.4. <a name='Preuvedetravail'></a>6.4. Preuve de travail
 
-Les objets `SharedPeer` indiquent les caractéristiques de la preuve de travail pour les messages de type `Message` et de type `MessageConnect` dans les attributs `pow_difficulty`, `pow_pattern`, , `pow_prefix`, `pow_nonce`, `pow_timeout`  du sous attribut `relay`. Les messages ne satisfaisant pas à la preuve de travail sont rejetés.
+Les objets `SharedPeer` indiquent les caractéristiques de la preuve de travail pour les messages de type `Message` et de type `MessageConnect` dans les attributs `pow_difficulty`, `pow_pattern`, `pow_prefix`, `pow_nonce`, `pow_timeout` du sous attribut `relay`. Les messages ne satisfaisant pas à la preuve de travail sont rejetés.
 
-### 6.5. <a name='AdresseSPdefaucet'></a>Adresse SP de faucet
+### 6.5. <a name='AdresseSPdefaucet'></a>6.5. Adresse SP de faucet
 
-L'utilisateur fourni aux relais une addresse Silent Payment (SP) dite de faucet `faucet_sp_address` (adresses publiques classiques générées depuis la clé privée du client).
+L'utilisateur fournit aux relais une adresse Silent Payment (SP) dite de faucet `faucet_sp_address` (adresses publiques classiques générées depuis la clé privée du client).
 
-L'utilisateur reçoit en retour une transaction Silent Payment (SP) contenant des jetons sur l'adresse dite de faucet `faucet_sp_address`, cette transaction contient un output suplémentaire avec le hash du message de type `MessageConnect` ou de type `Message` correspondant.
+L'utilisateur reçoit en retour une transaction Silent Payment (SP) contenant des jetons sur l'adresse dite de faucet `faucet_sp_address`, cette transaction contient un output supplémentaire avec le hash du message de type `MessageConnect` ou de type `Message` correspondant.
 
-## 7. <a name='Traitmentsparlesclients'></a>Traitments par les clients
+## 7. <a name='Traitementsparlesclients'></a>7. Traitements par les clients
 
-### 7.1. <a name='ConnexiondunclientsalisterelaisvialesmessagesdetypeMessageConnect'></a>Connexion d'un client à sa liste relais via les messages de type `MessageConnect`
+### 7.1. <a name='ConnexiondunclientsalisterelaisvialesmessagesdetypeMessageConnect'></a>7.1. Connexion d'un client à sa liste relais via les messages de type `MessageConnect`
 
-#### 7.1.1. <a name='Rcuprationetchoixdesrelais'></a>Récupération et choix des relais
+#### 7.1.1. <a name='Rcuprationetchoixdesrelais'></a>7.1.1. Récupération et choix des relais
 
 Afin de pouvoir discuter avec les relais du réseau et faire relayer des `PCD` et des `PRD` sous forme de `Message`, l'utilisateur doit se connecter à un ou plusieurs relais, 4 par défaut.
 
-L'utilisateur enverra un message de type `MessageConnect` à chaque relais pour se connecter. Puis il pourra envoyer des`Message` à chacun des 4 relais connectés et recevoir des `Message` de chacun des 4 relais connectés.
+L'utilisateur enverra un message de type `MessageConnect` à chaque relais pour se connecter. Puis, il pourra envoyer des `Message` à chacun des 4 relais connectés et recevoir des `Message` de chacun d'eux.
 
-Ainsi il y a des doubles des messages pour chaque relais à la fois envoyés et reçus. Un arbitrage est possible pour confronter les données dans le temps et par origines. Les résultats permettent d'améliorer les listes de membres par un système de réputation calculable par chacun de façon autonome en rapport à sa propre expérience. A ce stade l'arbitrage repose sur une réponse devant satisfaire au moins 80% de même réponse que des relais connectés pour le même message. Les valeurs des arbitrages sont stockées dans le cache.
+Ainsi, il y a des doublons des messages pour chaque relais à la fois envoyés et reçus. Un arbitrage est possible pour confronter les données dans le temps et par origines. Les résultats permettent d'améliorer les listes de membres par un système de réputation calculable par chacun de façon autonome en rapport à sa propre expérience. À ce stade, l'arbitrage repose sur une réponse devant satisfaire au moins 80% de même réponse que des relais connectés pour le même message. Les valeurs des arbitrages sont stockées dans le cache.
 
-Pour s'y connecter l'utilisateur récupère leurs caractéristiques depuis la liste de relais partagée `SharedPeerList` du SDK (Wasm) et depuis la liste de relais non partagée `private` du cache et depuis la liste de relais non partagée `public` du cache.
+Pour s'y connecter, l'utilisateur récupère leurs caractéristiques depuis la liste de relais partagée `SharedPeerList` du SDK (Wasm) et depuis la liste de relais non partagée `private` du cache et depuis la liste de relais non partagée `public` du cache.
 
-Un ping (PoW inclue dans le delai) est réalisé sur chaque relais pour vérifier leur disponibilité et l'on choisit les 4 premiers relais disponibles. Les valeurs des pings sont stockées dans le cache pour chaque relais (historique des pings).
+Un ping (PoW incluse dans le délai) est réalisé sur chaque relais pour vérifier leur disponibilité et l'on choisit les 4 premiers relais disponibles. Les valeurs des pings sont stockées dans le cache pour chaque relais (historique des pings).
 
-Les relais dits "navigators" ont un nom de domaine et un certificat SSL afin de satisfaires aux exigences de sécurité des navigateurs. Les autres relais n'ont pas de nom spécifique et n'ont pas nécessairement de nom de domaine et de certificat SSL, ils sont utilisés pour relayer les messages entre les relais.
+Les relais dits "navigators" ont un nom de domaine et un certificat SSL afin de satisfaire aux exigences de sécurité des navigateurs. Les autres relais n'ont pas de nom spécifique et n'ont pas nécessairement de nom de domaine et de certificat SSL, ils sont utilisés pour relayer les messages entre les relais.
 
 Les connexions sont en websocket avec ou sans SSL (url commençant par `ws://` ou `wss://`) et les messages sont en JSON.
 
-#### 7.1.2. <a name='EnvoidumessagedetypeMessageConnectchaquerelais'></a>Envoi du message de type `MessageConnect` à chaque relais
+#### 7.1.2. <a name='EnvoidumessagedetypeMessageConnectchaquerelais'></a>7.1.2. Envoi du message de type `MessageConnect` à chaque relais
 
-L'utilisateur parcours sa liste de relais et envoie un message de type `MessageConnect` en JSON (voir [Specs-Datamodel.md](Specs-Datamodel.md)) à chaque relais pour se connecter, il partage sa liste de relais et sa liste de process.
+L'utilisateur parcourt sa liste de relais et envoie un message de type `MessageConnect` en JSON (voir [Specs-Datamodel.md](Specs-Datamodel.md)) à chaque relais pour se connecter, il partage sa liste de relais et sa liste de process.
 
 Il n'y a pas de retour attendu pour ce message.
 
-### 7.2. <a name='EnvoidePCDsurlesrelaisvialesmessagesdetypeMessage'></a>Envoi de PCD sur les relais via les messages de type `Message`
+### 7.2. <a name='EnvoidePCDsurlesrelaisvialesmessagesdetypeMessage'></a>7.2. Envoi de PCD sur les relais via les messages de type `Message`
 
 Une fois le `PCD` finalisé, il est chiffré par la `ProcessKey` du process. Cette partie chiffrée est la valeur de l'attribut `request_enc` du `Message`.
 
-L'utilisateur parcours sa liste de relais et envoie un message correspondant de type `Message` en JSON (voir [Specs-Datamodel.md](Specs-Datamodel.md)) à chaque relais pour se connecter, il partage sa liste de relais et sa liste de process.
+L'utilisateur parcourt sa liste de relais et envoie un message correspondant de type `Message` en JSON (voir [Specs-Datamodel.md](Specs-Datamodel.md)) à chaque relais pour se connecter, il partage sa liste de relais et sa liste de process.
 
-### 7.3. <a name='EnvoidePRDsurlesrelaisvialesmessagesdetypeMessage'></a>Envoi de PRD sur les relais via les messages de type `Message`
+### 7.3. <a name='EnvoidePRDsurlesrelaisvialesmessagesdetypeMessage'></a>7.3. Envoi de PRD sur les relais via les messages de type `Message`
 
-Une fois le `PRD` finalisé, une transaction SP est réalisée, dans cette transactions plusieurs hashs sont ajoutés sur des outputs aux indexs suivants:
+Une fois le `PRD` finalisé, une transaction SP est réalisée, dans cette transaction plusieurs hashs sont ajoutés sur des outputs aux indexs suivants:
 
 1. Le hash du message de type `Message` correspondant
 2. Le hash du `PRD`
 3. Le hash du process
 4. Le hash de l'`item_name` de l'`Item` concerné
 5. Le hash de la valeur de la signature (attribut `sig_value` du PRD)
-6. Le hash du `PRD` d'origne associé au PRD  (le cas échéant)
-7. Le hash du `PCD` d'origine associé au PRD  (le cas échéant)
-8. Le hash du `PCD` de référence associé au PRD  (le cas échéant)
-9. Le hash d'un `Amount` de payment (le cas échéant)
-10. Le hash d'un `Amount` de deposit (le cas échéant)
-11. Un hash d'un commitment externe ou d'un `Number` (le cas échéant)
+6. Le hash du `PRD` d'origine associé au PRD (le cas échéant)
+7. Le hash du `PCD` d'origine associé au PRD (le cas échéant)
+8. Le hash du `PCD` de référence associé au PRD (le cas échéant)
+9. Le hash d'un `Amount` de paiement (le cas échéant)
+10. Le hash d'un `Amount`de dépôt (le cas échéant)
+11. Un hash d'un engagement externe ou d'un `Number` (le cas échéant)
 
 La clé `KeyConfidential` de cette transaction est utilisée pour chiffrer les champs suivants :
 
@@ -218,37 +215,37 @@ Pour les PRD de type `PRDKeyHello` :
 
 Puis le `PRD` est chiffré par la `ProcessKey` du process. Cette partie chiffrée est la valeur de l'attribut `request_enc` du `Message`.
 
-L'utilisateur parcours sa liste de relais et envoie un message correspondant de type `Message` en JSON (voir [Specs-Datamodel.md](Specs-Datamodel.md)) à chaque relais pour se connecter, il partage sa liste de relais et sa liste de process.
+L'utilisateur parcourt sa liste de relais et envoie un message correspondant de type `Message` en JSON (voir [Specs-Datamodel.md](Specs-Datamodel.md)) à chaque relais pour se connecter, il partage sa liste de relais et sa liste de process.
 
-### 7.4. <a name='TraitementdesmessagesdetypeMessageparlesclients'></a>Traitement des messages de type `Message` par les clients
+### 7.4. <a name='TraitementdesmessagesdetypeMessageparlesclients'></a>7.4. Traitement des messages de type `Message` par les clients
 
 Le client reçoit un nouveau message dans le socket ouvert avec le relais.
 
 Le client réalise les contrôles suivants :
 
-* Calcul du hash du message et vérification de la non existance du hash dans le cache.
+* Calcul du hash du message et vérification de la non-existence du hash dans le cache.
 
 Le client met à jour ses propres listes suivantes :
 
 * Liste des relais depuis la liste partagée par le relais `SharedPeerList`.
 * Liste des process depuis la liste partagée par le relais `SharedProcessList`.
 
-Déchiffrement du message avec la `ProcessKey` du process et controles suivants :
+Déchiffrement du message avec la `ProcessKey` du process et contrôles suivants :
 
-* Calcul du hash du PCD ou PRD et vérification de la non existance du hash dans le cache.
+* Calcul du hash du PCD ou PRD et vérification de la non-existence du hash dans le cache.
 * Voir [PRD-PCD-Specs.md](PRD-PCD-Specs.md) pour les détails des contrôles.
 
-Mises à jours des données du cache.
+Mises à jour des données du cache.
 
-## 8. <a name='Traitementsparlesrelais'></a>Traitements par les relais
+## 8. <a name='Traitementsparlesrelais'></a>8. Traitements par les relais
 
-### 8.1. <a name='TraitementdesmessagesdetypeMessageConnectparlesrelais'></a>Traitement des messages de type `MessageConnect` par les relais
+### 8.1. <a name='TraitementdesmessagesdetypeMessageConnectparlesrelais'></a>8.1. Traitement des messages de type `MessageConnect` par les relais
 
-Le relais enregistre le socket du client et lui attribut un index dans l'ordre de création des sockets.
+Le relais enregistre le socket du client et lui attribue un index dans l'ordre de création des sockets.
 
 Le relais réalise les contrôles suivants :
 
-* Calcul du hash du message et vérification de la non existance du hash dans le cache.
+* Calcul du hash du message et vérification de la non-existence du hash dans le cache.
 * Vérification de la preuve de travail.
 * Vérification de la taille des données.
 
@@ -257,27 +254,27 @@ Le relais met à jour ses propres listes suivantes :
 * Liste des relais depuis la liste partagée par le client `SharedPeerList`.
 * Liste des process depuis la liste partagée par le client `SharedProcessList`.
 
-Le relais envoit en retour quelques jetons sur une adresse dite de faucet `faucet_sp_address` communiquée par le client.
+Le relais envoie en retour quelques jetons sur une adresse dite de faucet `faucet_sp_address` communiquée par le client.
 
-Mises à jours des données du cache.
+Mises à jour des données du cache.
 
-Envoi de la transaction Silent Payment (SP) contenant des jetons sur l'adresse dite de faucet `faucet_sp_address` avec un output suplémentaire avec le hash du message de type `MessageConnect` correspondant.
+Envoi de la transaction Silent Payment (SP) contenant des jetons sur l'adresse dite de faucet `faucet_sp_address` avec un output supplémentaire avec le hash du message de type `MessageConnect` correspondant.
 
-### 8.2. <a name='ConnexionaurseauderelaisvialesmessagesdetypeMessageConnectparlesrelais'></a>Connexion au réseau de relais via les messages de type `MessageConnect` par les relais
+### 8.2. <a name='ConnexionaurseauderelaisvialesmessagesdetypeMessageConnectparlesrelais'></a>8.2. Connexion au réseau de relais via les messages de type `MessageConnect` par les relais
 
-Le relais parcoure la liste de relais mise à jour et se connecte à chacun des nouveaux relais via un `MessageConnect` en partageant à son tour sa liste de relais et sa liste de process.
+Le relais parcourt la liste de relais mise à jour et se connecte à chacun des nouveaux relais via un `MessageConnect` en partageant à son tour sa liste de relais et sa liste de process.
 
-Envoi vers chaque nouveau relai d'une transaction Silent Payment (SP) contenant des jetons sur l'adresse dite de faucet `faucet_sp_address` avec un output suplémentaire avec le hash du message de type `MessageConnect` correspondant.
+Envoi vers chaque nouveau relai d'une transaction Silent Payment (SP) contenant des jetons sur l'adresse dite de faucet `faucet_sp_address` avec un output supplémentaire avec le hash du message de type `MessageConnect` correspondant.
 
 Il n'y a pas de retour attendu pour ce message.
 
-## 9. <a name='TraitementdesmessagesdetypeMessageparlesrelais'></a>Traitement des messages de type `Message` par les relais
+## 9. <a name='TraitementdesmessagesdetypeMessageparlesrelais'></a>9. 9. Traitement des messages de type `Message` par les relais
 
 Le relais reçoit un nouveau message dans le socket ouvert avec le client.
 
 Le relais réalise les contrôles suivants :
 
-* Calcul du hash du message et vérification de la non existance du hash dans le cache.
+* Calcul du hash du message et vérification de la non-existence du hash dans le cache.
 * Vérification de la preuve de travail.
 * Vérification de la taille des données.
 
@@ -286,63 +283,65 @@ Le relais met à jour ses propres listes suivantes :
 * Liste des relais depuis la liste partagée par le client `SharedPeerList`.
 * Liste des process depuis la liste partagée par le client `SharedProcessList`.
 
-Le relais envoit en retour quelques jetons sur une adresse dite de faucet `faucet_sp_address` communiquée par le client.
+Le relais envoie en retour quelques jetons sur une adresse dite de faucet `faucet_sp_address` communiquée par le client.
 
-Mises à jours des données du cache.
+Mises à jour des données du cache.
 
-Envoi de la transaction Silent Payment (SP) contenant des jetons sur l'adresse dite de faucet `faucet_sp_address` avec un output suplémentaire avec le hash du message de type `MessageConnect` correspondant.
+Envoi de la transaction Silent Payment (SP) contenant des jetons sur l'adresse dite de faucet `faucet_sp_address` avec un output supplémentaire avec le hash du message de type `MessageConnect` correspondant.
 
-### 9.1. <a name='BroadcastdesmessagesdetypeMessageverslesrelais'></a>Broadcast des messages de type `Message` vers les relais
+### 9.1. <a name='BroadcastdesmessagesdetypeMessageverslesrelais'></a>9.1. Broadcast des messages de type `Message` vers les relais
 
-Le relais parcoure la liste de relais mise à jour et se connecte à chacun des nouveaux relais via un `MessageConnect` en partageant à son tour sa liste de relais et sa liste de process.
+Le relais parcourt la liste de relais mise à jour et se connecte à chacun des nouveaux relais via un `MessageConnect` en partageant à son tour sa liste de relais et sa liste de process.
 
-Envoi vers chaque nouveau relai d'une transaction Silent Payment (SP) contenant des jetons sur l'adresse dite de faucet `faucet_sp_address` avec un output suplémentaire avec le hash du message de type `MessageConnect` correspondant.
+Envoi vers chaque nouveau relai d'une transaction Silent Payment (SP) contenant des jetons sur l'adresse dite de faucet `faucet_sp_address` avec un output supplémentaire avec le hash du message de type `MessageConnect` correspondant.
 
-Envoi vers chaque relai d'une transaction Silent Payment (SP) contenant des jetons sur l'adresse dite de faucet `faucet_sp_address` avec un output suplémentaire avec le hash du message de type `Message` correspondant.
+Envoi vers chaque relai d'une transaction Silent Payment (SP) contenant des jetons sur l'adresse dite de faucet `faucet_sp_address` avec un output supplémentaire avec le hash du message de type `Message` correspondant.
 
-Le relais parcoure la liste de relais mise à jour et envoie le `Message`  reçu à chaque relai connecté en partageant à son tour sa liste de relais et sa liste de process (sans modifier la Preuve de Travail mais en contrôlant la taille du message et les caractéristiques de la preuve de travail avant d'envoyer au relai).
+Le relais parcourt la liste de relais mise à jour et envoie le `Message` reçu à chaque relai connecté en partageant à son tour sa liste de relais et sa liste de process (sans modifier la Preuve de Travail mais en contrôlant la taille du message et les caractéristiques de la preuve de travail avant d'envoyer au relai).
 
 Il n'y a pas de retour attendu pour ce message.
 
-### 9.2. <a name='BroadcastdesmessagesdetypeMessageverslesclientsconnects'></a>Broadcast des messages de type `Message` vers les clients connectés
+### 9.2. <a name='BroadcastdesmessagesdetypeMessageverslesclientsconnects'></a>9.2. Broadcast des messages de type `Message` vers les clients connectés
 
-Le relais parcoure la liste des sockets ouverts et envoie le `Message` reçu  à chaque client connecté en partageant à son tour sa liste de relais et sa liste de process.
+Le relais parcourt la liste des sockets ouverts et envoie le `Message` reçu à chaque client connecté en partageant à son tour sa liste de relais et sa liste de process.
 
-Envoi vers chaque client d'une transaction Silent Payment (SP) contenant des jetons sur l'adresse dite de faucet `faucet_sp_address` avec un output suplémentaire avec le hash du message de type `Message` correspondant.
+Envoi vers chaque client d'une transaction Silent Payment (SP) contenant des jetons sur l'adresse dite de faucet `faucet_sp_address` avec un output supplémentaire avec le hash du message de type `Message` correspondant.
 
 Il n'y a pas de retour attendu pour ce message.
 
-## 10. <a name='Connexionsauxrseauxdenoeudsdebitcoinderseauxsidechainoumainnet'></a>Connexions aux réseaux de noeuds de bitcoin de réseaux side chain ou mainnet
+## 10. <a name='Connexionsauxrseauxdenoeudsdebitcoinderseauxsidechainoumainnet'></a>10. Connexions aux réseaux de noeuds de bitcoin de réseaux side chain ou mainnet
 
-### 10.1. <a name='ProtocoledeDcouvertedesPairs'></a>Protocole de Découverte des Pairs
+Pour plus de détails, voir : [Specs-References.md](Specs-References.md).
+
+### 10.1. <a name='ProtocoledeDcouvertedesPairs'></a>10.1. Protocole de Découverte des Pairs
 
 Bitcoin utilise un mécanisme de découverte de pairs pour que les nouveaux nœuds puissent trouver d'autres nœuds du réseau. Cela peut être réalisé via des "DNS seeds" (des serveurs DNS qui retournent une liste d'adresses IP de nœuds Bitcoin actifs) ou via une liste de nœuds connus codée en dur dans le logiciel.
 
 * **Gossip Protocol** : Bitcoin utilise un protocole de type "gossip" pour la propagation des transactions. Lorsqu'un nœud reçoit une transaction valide qu'il n'a pas encore vue, il la valide puis la retransmet à tous ses pairs, ce qui permet une propagation rapide et efficace à travers le réseau.
 
-Dans le cas de 4NK l'équivalent des DNS est la liste de relais partagée `SharedPeerList`.
+Dans le cas de 4NK, l'équivalent des DNS est la liste de relais partagée `SharedPeerList`.
 
-### 10.2. <a name='ProtocoledeTransmissiondesTransactions'></a> Protocole de Transmission des Transactions
+### 10.2. <a name='ProtocoledeTransmissiondesTransactions'></a>10.2. Protocole de Transmission des Transactions
 
 * **Mempool et Transactions Orphelines** : Lorsqu'un nœud reçoit une nouvelle transaction, il l'ajoute à son pool de transactions en attente (mempool) avant de la transmettre à ses pairs. Si une transaction fait référence à des entrées inexistantes (par exemple, si elle dépend de transactions non confirmées), elle peut être traitée comme orpheline jusqu'à ce que ses dépendances soient résolues.
 
 Le protocole P2P de Bitcoin définit la manière dont les nœuds communiquent entre eux pour partager les informations sur les transactions et les blocs. Il inclut plusieurs types de messages :
 
-* **version / verack**: Utilisés lors de l'établissement de la connexion entre deux nœuds pour échanger les informations de version et confirmer la connexion.
+* **version / verack** : Utilisés lors de l'établissement de la connexion entre deux nœuds pour échanger les informations de version et confirmer la connexion.
 
 * **Protocole inv (inventaire)** : Un nœud annonce de nouvelles transactions à ses pairs en utilisant des messages inv, qui contiennent des identifiants de transaction. Les nœuds qui n'ont pas ces transactions peuvent alors les demander en utilisant des messages getdata.
 
-* **getdata**: Utilisé par un nœud pour demander les données spécifiques (transactions ou blocs) annoncées via un message inv.
+* **getdata** : Utilisé par un nœud pour demander les données spécifiques (transactions ou blocs) annoncées via un message inv.
 
-* **tx**: Utilisé pour transmettre les détails d'une transaction.
+* **tx** : Utilisé pour transmettre les détails d'une transaction.
 
-* **block**: Utilisé pour transmettre les détails d'un bloc.
+* **block** : Utilisé pour transmettre les détails d'un bloc.
 
-* **getblocks / getheaders**: Utilisés pour récupérer des blocs ou des en-têtes de blocs depuis un nœud, généralement dans le processus de synchronisation de la blockchain.
+* **getblocks / getheaders** : Utilisés pour récupérer des blocs ou des en-têtes de blocs depuis un nœud, généralement dans le processus de synchronisation de la blockchain.
 
-* **headers**: Utilisé pour transmettre des en-têtes de blocs en réponse à un message getheaders, facilitant la vérification et la synchronisation de la blockchain sans télécharger tous les blocs complets.
+* **headers** : Utilisé pour transmettre des en-têtes de blocs en réponse à un message getheaders, facilitant la vérification et la synchronisation de la blockchain sans télécharger tous les blocs complets.
 
-### 10.3. <a name='ProtocoledePartagedesBlocs'></a>Protocole de Partage des Blocs
+### 10.3. <a name='ProtocoledePartagedesBlocs'></a>10.3. Protocole de Partage des Blocs
 
 * **Propagation des Blocs** : Lorsqu'un nœud mine un nouveau bloc, il le transmet immédiatement à ses pairs. Comme pour les transactions, la propagation utilise un mécanisme similaire au protocole "gossip" pour assurer une distribution rapide du bloc à travers le réseau.
 
@@ -350,70 +349,53 @@ Le protocole P2P de Bitcoin définit la manière dont les nœuds communiquent en
 
 * **Protocole inv pour les blocs** : Similaire aux transactions, un nœud utilise des messages inv pour annoncer de nouveaux blocs à ses pairs. Les nœuds qui ne connaissent pas ce bloc peuvent demander le bloc complet en utilisant getdata.
 
-* **Transaction Relay Protocol**: Bitcoin Core a implémenté des améliorations telles que le "Transaction Relay Protocol" pour optimiser la manière dont les transactions sont relayées entre les nœuds, réduisant la bande passante nécessaire et améliorant la confidentialité.
+* **Transaction Relay Protocol** : Bitcoin Core a implémenté des améliorations telles que le "Transaction Relay Protocol" pour optimiser la manière dont les transactions sont relayées entre les nœuds, réduisant la bande passante nécessaire et améliorant la confidentialité.
 
-* **Compact Block Relay**: Ce protocole permet une propagation plus efficace des nouveaux blocs en utilisant les informations que les nœuds ont probablement déjà en leur possession, réduisant ainsi la quantité de données nécessaires à transmettre pour relayer un bloc complet.
+* **Compact Block Relay** : Ce protocole permet une propagation plus efficace des nouveaux blocs en utilisant les informationsque les nœuds ont probablement déjà en leur possession, réduisant ainsi la quantité de données nécessaires à transmettre pour relayer un bloc complet.
 
-Dans le cas de 4NK les block relay, compact blocks et les blocs filters permettent de travailler rapidement et côté client directement sur les données des blocs et transactions du réseau.
+Dans le cas de 4NK, les block relay, compact blocks, et les blocs filters permettent de travailler rapidement et côté client directement sur les données des blocs et transactions du réseau.
 
-### 10.4. <a name='Validationetrelais'></a>Validation et relais
+### 10.4. <a name='Validationetrelais'></a>10.4. Validation et relais
 
 * **Validation** : Les nœuds valident les transactions et les blocs selon les règles de consensus de Bitcoin et les règles de filtrage local avant de les relayer à d'autres nœuds. Cela inclut la vérification des signatures, la conformité des structures de données, et d'autres critères spécifiques à Bitcoin.
 
 * **Relais** : Après validation, les transactions et les blocs sont relayés aux autres pairs, favorisant ainsi la propagation rapide et la redondance des données à travers le réseau.
 
-### 10.5. <a name='GestiondesForks'></a>Gestion des Forks
+### 10.5. <a name='GestiondesForks'></a>10.5. Gestion des Forks
 
 Lorsque deux blocs sont minés presque simultanément, cela peut créer une bifurcation temporaire dans la blockchain. Les nœuds choisissent le premier bloc qu'ils reçoivent et continuent à construire dessus, mais ils gardent aussi une trace de la branche alternative. Si la branche alternative devient plus longue (c'est-à-dire qu'elle devient la chaîne avec le plus de travail cumulé), les nœuds basculent sur cette chaîne, réorganisant ainsi leur blockchain locale.
-Sécurité et Résilience
 
-Le réseau P2P de Bitcoin est conçu pour être résilient aux attaques et aux pannes. La nature décentralisée du réseau signifie qu'il n'y a pas de point de défaillance unique, et les mécanismes de consensus garantissent que tous les nœuds peuvent s'accorder sur l'état valide de la blockchain, même en présence de nœuds malveillants.
+### 10.6. <a name='Connexionaurseaudenudsdesidechain'></a>10.6. Connexion au réseau de nœuds de side chain
 
-Ces protocoles et mécanismes permettent à Bitcoin de fonctionner de manière décentralisée, sécurisée et scalable, assurant la transmission fiable et efficace des transactions et des blocs à travers
+#### 10.6.1. <a name='Clients'></a>10.6.1. Clients
 
-### 10.6. <a name='Connexionaurseaudenodesdesidechain'></a>Connexion au réseau de nodes de side chain
+Les clients se connectent comme un nœud depuis le SDK au réseau de nœuds de side chain via les protocoles p2p de Bitcoin. Ils reçoivent les blocs et les transactions (mempool) de la side chain et scannent les transactions de la side chain pour trouver les transactions Silent Payment (SP) correspondantes aux PRD, puis les PCD correspondant aux PRD.
 
-#### 10.6.1. <a name='Clients'></a>Clients
+#### 10.6.2. <a name='Relais-1'></a>10.6.2. Relais
 
-Les clients se connectent comme un noeud depuis le SDK au réseau de nodes de side chain via les protocoles p2p de Bitcoin.
+Les relais hébergent un nœud complet de la side chain, connecté aux autres membres de ce réseau. Voir [Specs-Deployment.md](Specs-Deployment.md) pour les détails de déploiement.
 
-Les clients reçoivent les blocs et les transactions (mempool) de la side chain.
+### 10.7. <a name='Connexionaurseaudenudsdelayer1'></a>10.7. Connexion au réseau de nœuds de layer 1
 
-Les clients scannent les transactions de la side chain pour trouver les transactions Silent Payment (SP) correspondantes aux PRD, puis les PCD correspondant aux PRD.
+Les relais hébergent un nœud complet du mainnet, connecté aux autres membres de ce réseau. Voir [Specs-Deployment.md](Specs-Deployment.md) pour les détails de déploiement.
 
-#### 10.6.2. <a name='Relais-1'></a>Relais
+### 10.8. <a name='HorodatageetancragedesPRDvialestransactionsSilentPaymentSP'></a>10.8. Horodatage et ancrage des PRD via les transactions Silent Payment (SP)
 
-Les relais hébergent un noeud complet de la side chain, connecté aux autres membres de ce réseau.
-Voir [Specs-Deployment.md](Specs-Deployment.md) pour les détails de déploiement.
+Les PRD sont horodatés et ancrés sur la side chain via des transactions Silent Payment (SP) contenant les hashs des messages et des signatures associées (PRD). Ces transactions sont ajoutées aux blocs, eux-mêmes signés par les nœuds "certificator" de la side chain pour être ajoutés à cette timechain. La dépense des UTXO de la transaction Silent Payment (SP) vaut pour signature (validation de la possession de la clé privée associée). Voir [Specs-Deployment.md](Specs-Deployment.md) pour les détails de déploiement.
 
-### 10.7. <a name='Connexionaurseaudenodesdelayer1'></a>Connexion au réseau de nodes de layer 1
+## 11. <a name='11.TransactionsmainnetBitcoin'></a>## 11. Transactions mainnet Bitcoin
 
-Les relais hébergent un noeud complet du mainnet, connecté aux autres membres de ce réseau.
-Voir [Specs-Deployment.md](Specs-Deployment.md) pour les détails de déploiement.
+### 11.1. <a name='HorodatageetancragedesblocsdelasidechainsurBitcoin'></a>11.1. Horodatage et ancrage des blocs de la side chain sur Bitcoin
 
-### 10.8. <a name='HorodatageetancragedesPRDvialestransactionsSilentPaymentSP'></a>Horodatage et ancrage des PRD via les transactions Silent Payment (SP)
+Le temps de référence est en blocs. Tous les hashs de blocs de la side chain sont historisés par lots de 6 * 24 blocs. À toutes les hauteurs de blocs multiples de 144, chaque lot de hashs de blocs est l'objet lui-même d'un hash qui est inscrit dans un output de transaction sur Bitcoin (mainnet).
 
-Les PRD sont horodatés et ancrés sur la side chain via des transactions Silent Payment (SP) contenant les hashs des messages et des signatures associées (PRD).
+### 11.2. <a name='RemboursementdesfraisdhorodatageetancragedesblocsdelasidechainsurBitcoin'></a>11.2. Remboursement des frais d'horodatage et ancrage des blocs de la side chain sur Bitcoin
 
-Ces transactions sont ajoutées aux blocs, eux mêmes signés par les noeuds "certificator" de la side chain pour être ajoutés à cette timechain.
-Voir [Specs-Deployment.md](Specs-Deployment.md) pour les détails de déploiement.
-
-La dépense des UTXO de la transaction Silent Payment (SP) vaut pour signature (validation de la pocession de la clé privée associée).
-
-## 11. <a name='TransactionsmainnetBitcoin'></a>Transactions mainnet Bitcoin
-
-### 11.1. <a name='HorodatageetancragedesblocsdelasidechainsurBitcoin'></a>Horodatage et ancrage des blocs de la side chain sur Bitcoin
-
-Le temps de référence est en blocs.
-
-Tous les hashs de blocs de la side chain sont historisés par lots de 6 * 24 blocs.
-
-Soit à toutes les hauteurs de blocs multiples de 144, chaque lot de hashs de blocs est l'objet lui même d'un hash qui est inscrit dans un output de transaction sur Bitcoin (mainnet)
-
-### 11.2. <a name='RemboursementdesfraisdhorodatageetancragedesblocsdelasidechainsurBitcoin'></a>Remboursement des frais d'horodatage et ancrage des blocs de la side chain sur Bitcoin
-
-Le minage "vert" de 4NK permet de produire les jetons nécessaires au remboursement des frais d'horodatage et ancrage des blocs de la side chain sur Bitcoin.
+Le minage "vert" de 4NK permet de produire les jetons nécessaires au remboursement des frais d'horodatage et ancrage des blocs de la side chain sur Bitcoin. La dépense des UTXO de la transaction Silent Payment (SP) vaut pour signature (validation de la possession de la clé privée associée).
 
 ## 12. <a name='ExemplesdeCode'></a>Exemples de Code
 
-Extraits de code illustrant l'utilisation des PCD et PRD dans des scénarios réels.
+## Todo
+
+* [ ] Extraits de code illustrant l'utilisation des PCD et PRD dans des scénarios réels.
+* [ ] Diagrammes de séquences