## 4 Anonymity, Untraceability and Transactional Data Privacy (AUT) Protocol  
A secure protocol to achieve a participant's anonymity, untraceability and transactional data privacy in the SMP is presented in this section. Note that the anonymity, untraceability and transactional data privacy solutions in this work were provided during trading activities between participants. Thus, the protocol ensured the desired privacy parameters independent of the type of trading model (one-to-one or one-to-many) used in the SMP. In order to establish trusted message streams among the participants, a lightweight Bitmessage (L-Bitmessage) technique was adopted. This technique uses cryptographic proof-of-authority (PoA) and the sped up Rivest-Shamir-Adleman (RSA) cryptosystem along with a Chinese reminder theorem (CRT) for the encryption or decryption processes. The RSA cryptosystem is a commonly used public key cryptosystem for secure data transfers [31; 32]. Additionally, it is one of the oldest. The proposed protocol is presented in Algorithm 1, and the workflow is depicted in Figure 2. Similarly, Table 2 provides a brief description of the important notations used in this work. \begin{table}
\begin{tabular}{l l} \hline \hline
**Symbols** & **Definitions** \\ \hline \(ACM_{track}\) & Actual ID correlation matrix \\ \(\mathcal{A}\) & Adversary or attacker \\ \(\mathcal{A}^{\tau}\) & Attacker who reacts to all game difficulties with statistical inferences \\ \(\mathcal{C}\) & A challenger who knows the correct assignment of addresses (public keys) to blockchain users \\ \(\delta\) & An arbitrary bit chosen by \(\mathcal{C}\) \\ \(E_{rack}\) & Consists of extra information which can be extracted from the SMP by \(\mathcal{A}\) \\ \(Success_{A}\) & Extra success recorded by \(\mathcal{A}\) against \(\mathcal{A}^{\tau}\) \\ \(Failure_{A}\) & Extra failure recorded by \(\mathcal{A}\) against \(\mathcal{A}^{\tau}\) \\ \(n_{p}\) & Number of participants in SMP \\ \(n_{T}\) & Number of transactions which occurred during time frame \(\Delta\), \\ \(\mathcal{P}\) & Participant in the SMP \\ \(\Delta\), & Period of time for SMP trading \\ \(e/d\) & Public or private IDs \\ \((a_{0},a_{1},...a_{n})\) & Set of IDs in the SMP \\ \(Succ_{\mathcal{A}}\) & Success of \(\mathcal{A}\) in the game \\ \(\rho\) & The amount of running time of the attacker \(\mathcal{A}\) \\ \(\gamma\) & The fraction of IDs that cannot be correlated with other IDs \\ \(\omega_{i}\) & The request message \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Notations. During the first stage in Figure 2, both \(ProGW_{j}\) and \(ReqGW_{i}\) create new pairs of session IDs \((MSID_{ProGW_{ph}},MSID_{ProGW_{Pr}})\) and \((MSID_{ReqGW_{ph}},MSID_{ReqGW_{Pr}})\), respectively, from their original pairs of public and private keys at the beginning of each trading activity in the system. The IDs are used to represent \(ProGW_{j}\) and \(ReqGW_{i}\) during trading activities. The IDs are sessional, and therefore, they are discarded after one complete trading transaction session. Both the \(ProGW\) and \(ReqGW\) public pair session IDs are generally chosen to be of relatively small prime values and of low hamming weights to ensure speeding up of the encryption process with a negligible computing overhead. Thus, \(ProGW_{j}\) and \(ReqGW_{i}\) remain anonymous under the pseudonyms of \(MSID_{ProGW_{ph}}\) and \(MSID_{ReqGW_{ph}}\), respectively, as well as untraceable without revealing their true identities (public keys).