model.tex

\section{Our Model}
\label{model}
A cryptocurrency wallet facilitates the transfer of funds between individuals. The wallet contains the private keys that can be used to spend the user's cryptocurrency. With those private keys, it should be able to fulfill the following functions.

\begin{enumerate}
    \item Present the user with their balance.
    \item Allow the user create new valid transactions, given a description.
    \item Present the user with their transaction history.
\end{enumerate}

The lifecycle of the wallet is as follows.
\paragraph{Sync.}
First the user generates a new secret key or recovers from an existing secret key. The wallet then performs an initial synchronisation by using the network, in order to obtain everything necessary for it to be able to perform the aforementioned functions. We denote this synchronisation step as producing a wallet state $\textsf{wstate} \gets \text{Sync}_{\Gen, \mathcal{S}}(pk)$, where $\Gen$ is the genesis block of the blockchain and $\mathcal{S}$ a set of servers the wallet is allowed to interact with. After this initial synchronisation is complete, the wallet keeps using the network to stay up to date with relevant events such as the user receiving a new transaction. The user may shut down the wallet and start it at some other point in time, when the wallet will attempt to catch-up to the network in order to be one again usable.

\paragraph{Fund.}
The user may wish to create a new transaction. They specify a \emph{transaction description} to the wallet which includes the recipients and the amounts of cryptocurrency the user wishes to send to each one. To obtain the final valid transaction the user invokes a function $tx \gets \text{Fund}(sk, \textsf{wstate}, \textsf{description})$ which makes use of the user's secret key $sk$, the wallet state \textsf{wstate} obtained from the Sync function and the provided transaction \textsf{description}.

\paragraph{History.}
We model the transaction history as a function extracting it from the wallet state, namely $tx_1, \dots, tx_y \gets \text{History}(pk, \textsf{wstate})$.

\paragraph{Balance.}
The wallet provides a function to determine the balance of the user based on the wallet state as $\textsf{balance} \gets \text{Balance}(pk, \textsf{wstate})$.

\begin{definition}[Wallet Protocol]
A \emph{wallet protocol} $\pi_\text{wallet}$ with respect to some server protocol $\pi_\text{wallet-server}$ that each server $s \in \mathcal{S}$ implements and a blockchain rooted in $\Gen$ is defined as a tuple of functions $\tpl{\text{Sync}_{\Gen, \mathcal{S}}, \text{Fund}, \text{History}, \text{Balance}}$.
\end{definition}

\paragraph{Seeds.}
Bitcoin wallets traditionally generate a different address for every transaction description to use for the tranasction's change output. This however means that the user needs to periodically backup an ever-increasing number of secret keys or risk some of their coins. A solution to this was presented in 2011 in the form of ``hierarchical deterministic wallets''~\cite{first-deterministic,bip32}. A single secret called the \emph{seed} is used to deterministically generate all future secret keys of the wallet. It is thus necessary only to backup this seed for a user to be able to retain all their funds, no matter how long they will make use of the wallet for. It is possible for a master public key to be created that only gives access to the public keys that correspond to the private keys derivable from the secret seed. Whereas wallets in practice usually restore from a seed, we adopt the simplification that the wallet is called to restore from a signature scheme secret key. Restoring from the seed can be thought of as invoking the Sync protocol many times, starting from the first derivable public key of the seed and continuing until we reach a public key that seems unused. Additionally, in protocols when the public key is directly provided as part of synchronisation, the master public key could be provided instead so that the server has access to all of the wallet's public keys directly.