# A Blockchain-Based Protocol for Fair Delivery for Receips
## 5 Certified Delivery Protocol  
In this section, we provide a comprehensive explanation of the protocol, elaborating on each defined step. Figure 3 summarizes all the steps considered by the protocol. In the figure, the solid lines represent messages sent by the sender or recipient, whereas the dotted lines indicate events generated by the smart contract after successful function execution. \begin{table}
\begin{tabular}{l l} \hline \(A\) & Sender \\ \(B\) & Recipient \\ \(SC\) & Smart contract \\ @\(X\) & Blockchain address of entity \(X\) \\ \(M\) & Document to deliver \\ \(h()\) & One-way collision-resistant hash function \\ \(id\) & Identifier of a protocol execution \\ \(Sig_{X}(a)\) & Signature on element \(a\) made by entity \(X\) \\ \(K\) & Secure key to be used by a symmetric cipher \\ \(E_{K}(a)\) and \(D_{K}(a)\) & Symmetric encryption and decryption functions, respectively, \\  & on element \(a\) using symmetric key \(K\) \\ \hline \end{tabular}
\end{table} 
Table 1: Notation for the fair delivery for recepts protocol. **Step 1 (Off-chain message). ** The first step of the protocol is to compose an off-chain message that \(A\) sends to \(B\) containing the following information:  
\[id,\,t_{m},\,t_{d},\,C,\,h,\,\text{and}\,\,f(C),\]  
where  
* \(id\) is an identifier used to link all messages that are involved in the same execution of the protocol and is calculated as \(id=H(@A,@B,@SC,t_{m},t_{d},h)\);
* \(t_{m}\) is the timestamp of the creation of the first message, i.e., the time at which protocol execution begins;
* \(t_{d}\) is the deadline before which delivery execution has to be completed;
* \(C\) is the encrypted version of the message \(M\) with a symmetric key \(K\), namely \(C=E_{K}(M)\), along with any security parameter required for verifying the encryption;
* \(h\) is the hash of \(C\), namely \(h=H(C)\);
* \(f(C)\) is \(A\)'s signature on the previous information, namely \(f(C)=Sig_{A}(id,t_{m},t_{d},h)\). Once this information is received by \(B\), they can decide which of the following actions to take:  
* If they do not wish to receive the document, they simply do nothing. In this case, once the deadline \(t_{d}\) expires, \(A\) observes that \(B\) has not agreed to receive the document. * Otherwise, after verifying whether the information provided by the sender is correct and adequate, they proceed to Step 2. **Step 2 (Accepting delivery). ** If \(B\) agrees to receive the delivery, they execute this step. It triggers the generation of an on-chain transaction by calling the _accept_ function defined by the smart contract. Consequently, it generates an on-chain transaction (\(tx_{acceptB}\)) that is signed with the private key of \(B\), which corresponds to the public blockchain address @\(B\):  
\[tx_{acceptB}=accept(id,t_{d},h,f(C))\]  
Once this message is received by the smart contract, it verifies the provided information. If the deadline \(t_{d}\) has not yet expired, the provided \(id\) is correct and matches the received parameters, and the smart contract has not stored any other record related to \(id\), the smart contract stores the data received from \(B\), indexes them, links them to \(id\), modifies the delivery state to accepted and finally triggers an event that contains the evidence. Otherwise, the smart contract does not perform any action and effectively ignores the request. At this time, \(B\) has expressed their desire to receive the document, so \(A\) must provide the key \(K\) via Step 3 before the expiration of the deadline \(t_{d}\). Figure 3: Protocol specification. Step 3 (Publishing the key).After listening to the blockchain and detecting the event triggered by the smart contract after it has completed Step 2, \(A\) proceeds with the encryption key release. Once \(A\) is certain that the evidence carried by the blockchain event is correct and sound, \(A\) must provide \(B\) with the data required to obtain \(K\) by executing the \(publish\) function from the smart contract.