\documentclass{article}
\usepackage[]{float,latexsym,times}
\usepackage{amsfonts,amstext,amsmath,amssymb,amsthm}
\usepackage{mathrsfs}
\usepackage{bbm}
\usepackage{mathtools} % for dcases
\usepackage{paralist}  % for inparaenum
\usepackage{blkarray}  % for block matrices
\usepackage{pgf,tikz}
\usepackage{MnSymbol}  % \lsem, \rsem.

\usepackage[margin=0.8in]{geometry}
\usepackage{hyperref}

\newcommand{\ignore}[1]{}

% Math notation
\newcommand{\set}[1]{\left\{#1\right\}}
\newcommand{\bigset}[1]{\big\{#1\big\}}
\newcommand{\Bigset}[1]{\Big\{#1\Big\}}
\newcommand{\slfrac}[2]{\left. #1 \middle/ #2 \right.}
\newcommand{\ceil}[1]{\left\lceil #1 \right\rceil}
\newcommand{\floor}[1]{\left\lfloor #1 \right\rfloor}
\newcommand{\round}[1]{\left\lsem\, #1 \,\right\rsem}

% Probability notation
\renewcommand{\mspace}[1]{\mathscr{#1}}
\newcommand{\algebra}[1]{\mathscr{#1}}
\newcommand{\prob}[1]{\mathbf{#1}}
\newcommand{\cond}[2]{\left. {#1} \, \middle | \, {#2} \right.}
\newcommand{\ci}{\perp\!\!\!\perp}             % Conditional independence.
%\renewcommand{\Pr}{\operatorname{\mathbf{P}}}  % probability measure
\DeclareMathOperator{\EV}{\mathbf{E}}          % expected value
\DeclareMathOperator{\Var}{\mathbf{Var}}       % variance
\DeclareMathOperator{\Cov}{\mathbf{Cov}}       % covariance

% Probability distributions
\newcommand{\Binomial}{\mathrm{Bin}}

% Well-known sets
\newcommand{\tinyinfty}{\infty} % or {\scriptscriptstyle \infty}
\newcommand{\tinyzero}{0} % or {\scriptscriptstyle 0}
\newcommand{\One}{\mathchoice{\rm 1\mskip-4.2mu l}{\rm 1\mskip-4.2mu l}{\rm 1\mskip-4.6mu l}{\rm 1\mskip-5.2mu l}}
\newcommand{\Naturals}{\mathbb{N}}
\newcommand{\Reals}{\mathbb{R}}

% Styles
\renewcommand{\le}{\leqslant}
\renewcommand{\leq}{\leqslant}
\renewcommand{\ge}{\geqslant}
\renewcommand{\geq}{\geqslant}
\newcommand{\overwr}{\leftarrow}

% Short-hand notation
\newcommand{\cA}{\mathcal{A}}
\newcommand{\cG}{\mathcal{G}}
\newcommand{\cH}{\mathcal{H}}
\newcommand{\cI}{\mathcal{I}}
\newcommand{\cJ}{\mathcal{J}}

% Document-specific

% Spaces of:
\newcommand{\Sutype}{\mathcal{U}} % Unit types
\newcommand{\Sctype}{\mathcal{C}} % Camp types
\newcommand{\Sgtype}{\mathcal{G}} % Unit groups
\newcommand{\Satype}{\mathcal{A}} % Armies

% Properties
\DeclareMathOperator{\He}{{\sf He}} % Health.
\DeclareMathOperator{\DLow}{\underline{\sf Dm}} % Low damage.
\DeclareMathOperator{\DHigh}{\overline{\sf Dm}} % High damage.
\DeclareMathOperator{\A}{{\sf A}} % Generic attribute.
\DeclareMathOperator{\Acc}{{\sf Acc}} % Accuracy.
\DeclareMathOperator{\Spl}{{\sf Spl}} % Splash chance.
\DeclareMathOperator{\Red}{{\sf Red}} % Damage reduction.
\DeclareMathOperator{\Exp}{{\sf Exp}} % Experience.

% Theorems
\newtheorem{assumption}{Assumption}
\newtheorem{remark}{Remark}
\newtheorem{proposition}{Proposition}
\newtheorem{lemma}{Lemma}
\newtheorem{algorithm}{Algorithm}
\numberwithin{equation}{section}

\newenvironment{example}
  {\paragraph*{Example.}\begin{itemize}\item[]}
  {\end{itemize}}

\title{Divining the Combat System in the Settlers Online}
\date{}

%-------------------------------------------------------------------------------------------------%
\begin{document}

\maketitle

\paragraph*{Foreword.}
This paper is a short summary of how the combat mechanics work in the Settlers Online---based on scattered and scarce pieces of information from the forums from the developers, as well as testing on the main and pre-staging servers. Whenever a certain piece of information is not verified, it will be explicitly noted.

As an aside, the authors consider the adventure combat model only, and discard the expedition combat model as trivial and uninteresting.

\section{Units}
Each unit has a \emph{type}, prescribing the base attributes governing their behavior in a battle. These are:
\begin{itemize}
    \item hit points, which we will denote with $\He $;
    \item experience, $\Exp $---the amount of experience points the attacker gets when this unit is killed;
    \item low and high damage, denoted $\DLow $ and $\DHigh $, respectively;
    \item accuracy, $\Acc $, which is the probability of dealing high damage rather than low damage;
    \item splash chance, $\Spl $---probability that the inflicted damage will spill over to the next defender.
\end{itemize}
All of them, except for $\Acc $ and $\Spl $ are integer-valued.
%
Furthermore, each of the attributes can have \emph{modifiers}. Modifiers come in two flavors: absolute value modifier (additive modifier), and relative/rate modifier (multiplicative modifier). If $\A $ is the base value of any attribute, and ($x$, $r$) is the pair additive modifier/multiplicative modifier, then
\[
    \A + \round{r \A } + x
\]
will be the effective value of the attribute (c.f.\ \cite{dev-halloween:2018}), where $(r \A )$ is rounded for integer-valued attributes. How exactly it is rounded may depending on what $r$ is and which attribute we are talking about.

Based on some---not particularly extensive---testing (but with no reference to official sources) the authors believe that the rounding happens this way (here $r$ is the rate modifier):
\begin{itemize}
    \item $\He $ modifiers are rounded toward zero (down if $r > 0$, up if $r < 0$)---tested for $r > 0$, speculation otherwise;
    \item $\Exp $ modifiers are applied to groups rather than individual units, and are rounded toward zero (down if $r > 0$, up if $r < 0$)---tested for $r > 0$, speculation otherwise;
    \item $\DLow $ and $\DHigh $ modifiers are rounded away from zero (up if $r > 0$, down if $r < 0$)---tested for $r < 0$, speculation otherwise;
    \item $\Acc $ is not rounded---pure speculation;
    \item $\Spl $ is not rounded---pure speculation.
\end{itemize}

When there is more than one modifier, they stack as follows \cite{dev-halloween:2018}. If a base attribute $\A $ is being modified by two modifier pairs, $(x, r)$ and $(y, s)$, then
\[
    \A + \round{(r + s) \A } + (x + y)
\]
will be the effective value of the attribute.

The governing feature of the entire combat system is:
\begin{assumption}
    Units within an army attack sequentially, one at a time.
\end{assumption}
\begin{assumption}
    Opposing armies attack each other simultaneously: if a unit has survived to a stage when they are supposed to attack, they are guaranteed the opportunity to attack regardless of whether or not they are killed in this stage.
\end{assumption}

\begin{example}
    Two defending units---first with $4$ hit points, second with $6$ hit points---are attacked by a group with $\DHigh = 5$, $\DLow = 3$ and $\Spl = 0$.
    We will illustrate the consequences of changing the order of attack. To that end, consider two scenarios: the attacker deals \begin{inparaenum}[(i)]\item high, low, low; and \item low, low, high \end{inparaenum}.

    In the first case the defender's hit points will be $(4, 6) \to (0, 6) \to (0, 3) \to (0, 0)$.

    In the second case the defender's hit points will be $(4, 6) \to (1, 6) \to (0, 6) \to (0, 1)$.
\end{example}

\begin{example}
    Three units, $u_1$, $u_2$, and $u_2$, attack an enemy unit $v$. Let the attacker have $10\%$ damage bonus; let $v$ have $25$ hit points and damage reduction of $30\%$.

    Suppose first two attackers deal base high damage of $13$ each, and the last attacker deals base low damage of $6$. The inflicted damage from $u_1$ and $u_2$ will then be
    \[
        13 + \round{(0.1 - 0.3) \cdot 13} = 13 - \ceil{2.6} = 13 - 3 = 10
    \]
    each. Similarly, the inflicted damage from $u_3$ will be
    \[
        6 - \ceil{(0.2) \cdot 6} = 4.
    \]
    Thus the total damage will be $(10 + 10 + 4) = 24$, and $v$ will survive with $1$ hit point left.

    Note that if one dropped the assumption that units attacked sequentially, the inflicted damage would have been
    \[
        (13 + 13 + 6) - \ceil{(0.2) \cdot (13 + 13 + 6)} = 32 - 7 = 25
    \]
    instead, and $v$ would have died.
\end{example}

\section{To Splash or Not To Splash}\label{sec:splash}

Splash damage (as opposed to truncated---usual---damage) is the case when overshoot damage is spilled over to the next defending unit.
%
\begin{example}
    Suppose there are no damage modifiers, and $u$ attacks $v$---which has only $20$ hit points left---with $100$ damage. In either case $v$ will be killed. If this was a \emph{splash damage} attack, the remaining $80$ damage will be inflicted onto the next unit. If this was a \emph{truncated damage} attack, the remaining $80$ damage will be lost (discarded).
\end{example}

While this works nicely when damage modifiers are equal between groups, the moment damage modifiers are no longer homogeneous a big question arises: how does this difference affect overshoot damage?

The answer to this question is, perhaps, the weakest point of this work: not only is it not documented officially (according to the authors' knowledge), but it has not been tested either (partly because watchtower damage reduction has been removed from the game, and coming up with a conclusive setup seemed too challenging). In short, the following is merely a description of how the authors chose to implement it, and may have little to no relevance to the game.

Suppose a unit $u$ attacks group $G$ followed by group $H$. Let $(\underline{d}_G, \overline{d}_G)$ and $(\underline{d}_H, \overline{d}_H)$ denote the effective (after all bonuses have been applied) damage of $u$ vs.\ $G$ and $H$, respectively.
Denote the damage ratios with
\[
    \underline{r} = \frac{\underline{d}_H}{\underline{d}_G}
    \qquad \text{and} \qquad
    \overline{r} = \frac{\overline{d}_H}{\overline{d}_G}.
\]
Let $\o $ be the overshoot damage when $G$ is killed. If $G$ was killed with a low damage splash hit, then the damage spilled onto $H$ will be $\floor{\underline{r} \, \cdot \o }$. If the damage was high, the corresponding value will be $\floor{\overline{r} \, \cdot \o }$ instead.

\section{Special Abilities and Battle Structure}
In this section we briefly discuss battle or unit characteristics, modifiers, and abilities, that affect the normal course of the battle.

All modifiers to $\He $, $\Exp $, $\DLow $, and $\DHigh $ are stored separately from the base values. Effective values for $\He $ are calculated before the battle begins. Effective values for $\DLow $ and $\DHigh $ are calculated prior to each combat round.
Modifiers to $\Acc $ and $\Spl $, on the other hand, are applied before the battle directly to the base value which is then clipped to the interval $[0, 1]$.

Before the battle starts, there are two stages:
\begin{enumerate}[(i)]
    \item Pre-battle bonus stage: each army's bonuses are applied.
    \item Pre-battle penalty stage: each army's penalties are applied.
\end{enumerate}
This ordering ensures, for example, that if one army has explosive ammunition (granting friendly ranged units \emph{attack weakest target} ability) and the other has intercept (stripping enemy units of \emph{attack weakest target} ability), intercept will take precedence, and all of the units in the first army will \emph{not} have \emph{attack weakest target}.

\section{Combat Sequence}

In this section let $\He ^*$, $\DLow ^*$, $\DHigh ^*$, $\Acc ^*$, and $\Spl ^*$ denote the modified attributes (base values after the modifiers have been applied).

While the base damage dealt by any unit is independent of any other unit, the effective damage is not.
However, if the defending unit has $h$ hit points, it will take at least $k = \ceil{h / \DHigh ^*}$ units to eliminate it, implying that the first $k$ attacks \emph{will} be independent.
%
Having said that, the course of attack is outlined in the following algorithm.
\begin{algorithm}
    Consider a group $G = (u_1, u_2, \cdots , u_n)$ attacking an army $\cA = (v_1, v_2, \cdots , v_m)$.
    %
    Set $i = 1$ and $j = 1$, the (one-based) index of the attacking and defending units, respectively. Let $h = \He ^* (v_1)$ be the health of the first defending unit.
    %
    \begin{enumerate}
        \item \label{step:first_conservative} Let $\DHigh _j ^*$ and $\DLow _j ^*$ be the effective high and low damage against the current defending unit, and let $k = \ceil{h / \DHigh _j ^*}$ be the least number of attacking units required to kill the defender.

        \item If $k$ is greater than $(n - i + 1)$---the remaining units in the attacking group---update $k \overwr (n - i + 1)$.

        \item Generate $X \sim \mathrm{Bin} \left(k, \Acc ^* \right)$, the number of units dealing high damage, and let $d = \DHigh _j ^* \cdot \, X + \DLow _j ^* \cdot \, (k - X)$.

        \item Update $i \overwr i + k$ (point to the next attacking unit).

        \item Update $(h, d) \overwr (h - d, d - h)$ (damage the current defending unit, and store potential overshoot damage).

        \item If $h < 0$ (the current defending unit has been killed and there is still leftover damage), generate $Y \sim \mathrm{Bin} \left(1, \Spl _u \right)$, the chance of splash damage (note that it is not necessary if $h = 0$). Otherwise set $Y = 0$.

        \item If $Y = 0$ (no splash), update $d \overwr 0$ (no overshoot damage).

        \item While $h \leq 0$:
        \begin{enumerate}
            \item update $j \overwr j + 1$ (proceed to the next defending unit);
            \item if $j = m + 1$, terminate: the entire army $\cA $ has been eliminated;
            \item let $r$ denote the splash ratio factor between $v_j$ and $v_{j - 1}$ as explained in section \ref{sec:splash};
            \item update $h \overwr \He ^* (v_j)$ and $d \overwr \floor{r \cdot d}$;
            \item update $(h, d) \overwr (h - d, d - h)$ (damage the next defending unit, and store potential overshoot damage).
        \end{enumerate}

        \item \label{step:last_conservative} If $i = n + 1$, terminate: the entire group $G$ has attacked, and exactly $(j - 1)$ units from $\cA $ have been killed; the $j$-th unit in $\cA $ has only $h$ hit points left.

        \item Otherwise repeat steps \ref{step:first_conservative}--\ref{step:last_conservative}.
    \end{enumerate}
\end{algorithm}

\begin{thebibliography}{9}
    \bibitem{dev-halloween:2018} Official forums. \textit{[Dev Diary] Halloween 2018}, {https://forum.thesettlersonline.net/threads/25261\#post287808}.
\end{thebibliography}

\end{document}


%\documentclass[aps,showpacs,prb,floatfix,twocolumn]{revtex4}
\documentclass[aps,prb,floatfix,epsfig,singlecolumn,showpacs,preprintnumbers]{revtex4}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\usepackage{amsmath,amssymb,graphicx,bm,epsfig}
\usepackage{color}
\usepackage{braket}

\newcommand{\eps}{\epsilon}
\newcommand{\vR}{{\mathbf{R}}}
\newcommand{\vF}{{\mathbf{F}}}
\renewcommand{\vr}{{\mathbf{r}}}
\newcommand{\hr}{{\hat{\textbf{r}}}}
\newcommand{\vk}{{\mathbf{k}}}
\newcommand{\vdelta}{{\mathbf{\delta}}}
\newcommand{\vK}{{\mathbf{K}}}
\newcommand{\vG}{{\mathbf{G}}}
\newcommand{\vq}{{\mathbf{q}}}
\newcommand{\vQ}{{\mathbf{Q}}}
\newcommand{\vPhi}{{\mathbf{\Phi}}}
\newcommand{\vS}{{\mathbf{S}}}
\newcommand{\cG}{{\cal G}}
\newcommand{\cR}{{\cal R}}
\newcommand{\cF}{{\cal F}}
\newcommand{\cT}{{\cal T}}
\newcommand{\cO}{{\cal O}}
\newcommand{\cH}{{\cal H}}
\newcommand{\cJ}{{\cal J}}
\newcommand{\cD}{{\cal D}}
\newcommand{\cU}{{\cal U}}
\newcommand{\cL}{{\cal L}}
\newcommand{\Tr}{\mathrm{Tr}}
\renewcommand{\a}{\alpha}
\renewcommand{\b}{\beta}
\newcommand{\g}{\gamma}
\renewcommand{\d}{\delta}
\newcommand{\npsi}{\underline{\psi}}
\renewcommand{\Im}{\textrm{Im}}
\renewcommand{\Re}{\textrm{Re}}
\newcommand{\cA}{{\cal A}}
\newcommand{\vcA}{\vec{\cal A}}
\newcommand{\vcB}{\vec{\cal B}}
\newcommand{\vcC}{\vec{\cal C}}
\newcommand{\cB}{{\cal B}}
\newcommand{\cC}{{\cal C}}
\usepackage{hyperref}

\begin{document}

\title{Some notes on the Free Energy in DFT+DMFT}
\author{Kristjan Haule}
\affiliation{Department of Physics, Rutgers University, Piscataway, NJ 08854, USA}
\date{\today}

%\begin{abstract}
%\end{abstract}
\pacs{71.27.+a,71.30.+h}
\date{\today}
\maketitle

\section{How is Free energy implemented?}

The details of the algorithm are published in
\href{http://journals.aps.org/prl/abstract/10.1103/PhysRevLett.115.256402}{Phys. Rev. Lett. 115, 256402 (2015)}.
Here we just mention some implementation details, which are not
completely detailed there.

The total energy is printed in column six of \textit{info.iterate}. We
compute it by
\begin{eqnarray}
E_6=E^H[\rho]+E^{XC}[\rho]+E_{nuc}-\Tr((V_H+V_{XC})\rho)+
\textcolor{red}{\Tr(\varepsilon^{DFT}_\vk \rho)}+
\textcolor{blue}{E_{imp}^{pot}-\Phi^{DC}[n_{imp}]}
\end{eqnarray}
The blue terms are computed from the impurity quantities, and the
black and red
are computed from the lattice quantities. The black are evaluated in \textit{lapw0} and \textit{lapwc}. The red
terms are evaluated in \textit{dmft2}.

The free energy is printed in column seven and eight of
\textit{info.iterate}. The seventh column is computed by
\begin{eqnarray}
F_7=E^H[\rho]+E^{XC}[\rho]+E_{nuc}-\Tr((V_H+V_{XC})\rho)
+\textcolor{red}{\Tr\log( G)+\mu N-\Tr\log(G_{loc})+\Tr((\varepsilon_{imp}+V_{DC})n_{loc})}
\\
+\textcolor{blue}{E_{imp}^{pot}
+\Tr\left((\Delta-\omega_n\frac{d\Delta}{d\omega_n})G_{imp}\right)
-\Phi^{DC}[n_{imp}]}
-\textcolor{green}{T S_{imp}}
\end{eqnarray}
The blue terms are computed from the impurity quantities, and the
black and red
are computed from the lattice quantities. The black are evaluated in \textit{lapw0} and \textit{lapwc}. The red
terms are evaluated in \textit{dmft2}. The green term is missing in
\textit{info.iterate} and needs to be computed at postprocessing as
explained in the above PRL.

The eight column is computed by
\begin{eqnarray}
F_8=E^H[\rho]+E^{XC}[\rho]+E_{nuc}-\Tr((V_H+V_{XC})\rho)
+\textcolor{red}{\Tr\log( G)+\mu N-\Tr((\Sigma-V_{DC})G_{loc})}
\\
+\textcolor{blue}{E_{imp}^{pot}
+\Tr\left((\Delta-\omega_n\frac{d\Delta}{d\omega_n})G_{imp}\right)
-\Tr\log(G_{imp})+\Tr(\varepsilon_{imp}n_{imp})+\Tr(\Sigma_{imp}G_{imp})
-\Phi^{DC}[n_{imp}]}
-\textcolor{green}{T S_{imp}}
\end{eqnarray}

The difference between the seventh and eight column is then
\begin{eqnarray}
F_8-F_7 =
\textcolor{red}{\Tr\log(G_{loc})-\Tr(\Sigma G_{loc})-\Tr(\varepsilon_{imp}n_{loc})}
-\textcolor{blue}{\Tr\log(G_{imp})+\Tr(\Sigma G_{imp})+\Tr(\varepsilon_{imp}n_{imp})}
\end{eqnarray}

\end{document}


\section{Tendermint consensus algorithm} \label{sec:tendermint}

\newcommand\Disseminate{\textbf{Disseminate}}

\newcommand\Proposal{\mathsf{PROPOSAL}}
\newcommand\ProposalPart{\mathsf{PROPOSAL\mbox{-}PART}}
\newcommand\PrePrepare{\mathsf{INIT}} \newcommand\Prevote{\mathsf{PREVOTE}}
\newcommand\Precommit{\mathsf{PRECOMMIT}}
\newcommand\Decision{\mathsf{DECISION}}

\newcommand\ViewChange{\mathsf{VC}}
\newcommand\ViewChangeAck{\mathsf{VC\mbox{-}ACK}}
\newcommand\NewPrePrepare{\mathsf{VC\mbox{-}INIT}}
\newcommand\coord{\mathsf{proposer}}

\newcommand\newHeight{newHeight} \newcommand\newRound{newRound}
\newcommand\nil{nil} \newcommand\id{id} \newcommand{\propose}{propose}
\newcommand\prevote{prevote} \newcommand\prevoteWait{prevoteWait}
\newcommand\precommit{precommit} \newcommand\precommitWait{precommitWait}
\newcommand\commit{commit}

\newcommand\timeoutPropose{timeoutPropose}
\newcommand\timeoutPrevote{timeoutPrevote}
\newcommand\timeoutPrecommit{timeoutPrecommit}
\newcommand\proofOfLocking{proof\mbox{-}of\mbox{-}locking}

\begin{algorithm}[htb!] \def\baselinestretch{1} \scriptsize\raggedright
	\begin{algorithmic}[1]
		\SHORTSPACE
		\INIT{}
		\STATE $h_p := 0$
		\COMMENT{current height, or consensus instance we are currently executing}
		\STATE $round_p := 0$   \COMMENT{current round number}
		\STATE $step_p  \in \set{\propose, \prevote, \precommit}$
		\STATE $decision_p[] := nil$
		\STATE $lockedValue_p := nil$
		\STATE $lockedRound_p := -1$
		\STATE $validValue_p := nil$
		\STATE $validRound_p := -1$
		\ENDINIT
		\SHORTSPACE
		\STATE \textbf{upon} start \textbf{do} $StartRound(0)$
		\SHORTSPACE
		\FUNCTION{$StartRound(round)$} \label{line:tab:startRound}
		\STATE $round_p \assign round$
		\STATE $step_p \assign \propose$
		\IF{$\coord(h_p, round_p) = p$}
		\IF{$validValue_p \neq \nil$} \label{line:tab:isThereLockedValue}
		\STATE $proposal \assign validValue_p$ \ELSE \STATE $proposal \assign
		getValue()$
		\label{line:tab:getValidValue}
		\ENDIF
		\STATE \Broadcast\ $\li{\Proposal,h_p, round_p, proposal, validRound_p}$
		\label{line:tab:send-proposal}
		\ELSE
		\STATE \textbf{schedule} $OnTimeoutPropose(h_p,
		round_p)$ to be executed \textbf{after} $\timeoutPropose(round_p)$
		\ENDIF
		\ENDFUNCTION

		\SPACE
		\UPON{$\li{\Proposal,h_p,round_p, v, -1}$ \From\ $\coord(h_p,round_p)$
			\With\ $step_p = \propose$} \label{line:tab:recvProposal}
			\IF{$valid(v) \wedge (lockedRound_p = -1  \vee lockedValue_p = v$)}
			\label{line:tab:accept-proposal-2}
				\STATE \Broadcast \ $\li{\Prevote,h_p,round_p,id(v)}$
				\label{line:tab:prevote-proposal}
			\ELSE
			\label{line:tab:acceptProposal1}
				\STATE \Broadcast \ $\li{\Prevote,h_p,round_p,\nil}$
				\label{line:tab:prevote-nil}
			\ENDIF
				\STATE $step_p \assign \prevote$ \label{line:tab:setStateToPrevote1}
		\ENDUPON

		\SPACE
		\UPON{$\li{\Proposal,h_p,round_p, v, vr}$ \From\ $\coord(h_p,round_p)$
			\textbf{AND} $2f+1$ $\li{\Prevote,h_p, vr,id(v)}$  \With\ $step_p = \propose \wedge (vr \ge 0 \wedge vr < round_p)$}
		\label{line:tab:acceptProposal}
		\IF{$valid(v) \wedge (lockedRound_p \le vr
			\vee lockedValue_p = v)$} \label{line:tab:cond-prevote-higher-proposal}
			\STATE \Broadcast \ $\li{\Prevote,h_p,round_p,id(v)}$
			\label{line:tab:prevote-higher-proposal}
		\ELSE
			\label{line:tab:acceptProposal2}
			\STATE \Broadcast \ $\li{\Prevote,h_p,round_p,\nil}$
			\label{line:tab:prevote-nil2}
		\ENDIF
		\STATE $step_p \assign \prevote$ \label{line:tab:setStateToPrevote3}
		\ENDUPON

		\SPACE
		\UPON{$2f+1$ $\li{\Prevote,h_p, round_p,*}$ \With\ $step_p = \prevote$ for the first time}
		\label{line:tab:recvAny2/3Prevote}
		\STATE \textbf{schedule} $OnTimeoutPrevote(h_p, round_p)$ to be executed \textbf{after}  $\timeoutPrevote(round_p)$ \label{line:tab:timeoutPrevote}
		\ENDUPON

		\SPACE
		\UPON{$\li{\Proposal,h_p,round_p, v, *}$ \From\ $\coord(h_p,round_p)$
			\textbf{AND} $2f+1$ $\li{\Prevote,h_p, round_p,id(v)}$  \With\ $valid(v) \wedge step_p \ge \prevote$ for the first time}
		\label{line:tab:recvPrevote}
		\IF{$step_p = \prevote$}
			\STATE $lockedValue_p \assign v$                \label{line:tab:setLockedValue}
			\STATE $lockedRound_p \assign round_p$   \label{line:tab:setLockedRound}
			\STATE \Broadcast \ $\li{\Precommit,h_p,round_p,id(v))}$
			\label{line:tab:precommit-v}
			\STATE $step_p \assign \precommit$ \label{line:tab:setStateToCommit}
		\ENDIF
		\STATE $validValue_p \assign v$ \label{line:tab:setValidRound}
		\STATE $validRound_p \assign round_p$ \label{line:tab:setValidValue}
		\ENDUPON

		\SHORTSPACE
		\UPON{$2f+1$ $\li{\Prevote,h_p,round_p, \nil}$
			\With\ $step_p = \prevote$}
			\STATE \Broadcast \ $\li{\Precommit,h_p,round_p, \nil}$
			\label{line:tab:precommit-v-1}
			\STATE $step_p \assign \precommit$
		\ENDUPON

		\SPACE
		\UPON{$2f+1$ $\li{\Precommit,h_p,round_p,*}$ for the first time}
		\label{line:tab:startTimeoutPrecommit}
			\STATE \textbf{schedule} $OnTimeoutPrecommit(h_p, round_p)$ to be executed \textbf{after} $\timeoutPrecommit(round_p)$

		\ENDUPON

		\SPACE
		\UPON{$\li{\Proposal,h_p,r, v, *}$ \From\ $\coord(h_p,r)$ \textbf{AND}
			$2f+1$ $\li{\Precommit,h_p,r,id(v)}$ \With\ $decision_p[h_p] = \nil$}
		\label{line:tab:onDecideRule}
			\IF{$valid(v)$} \label{line:tab:validDecisionValue}
				\STATE $decision_p[h_p] = v$ \label{line:tab:decide}
				\STATE$h_p \assign h_p + 1$ \label{line:tab:increaseHeight}
				\STATE reset $lockedRound_p$, $lockedValue_p$, $validRound_p$ and $validValue_p$ to initial values
				and empty message log
				\STATE $StartRound(0)$
			\ENDIF
		\ENDUPON

		\SHORTSPACE
		\UPON{$f+1$ $\li{*,h_p,round, *, *}$ \textbf{with} $round > round_p$}
		\label{line:tab:skipRounds}
			\STATE $StartRound(round)$ \label{line:tab:nextRound2}
		\ENDUPON

		\SHORTSPACE
		\FUNCTION{$OnTimeoutPropose(height,round)$} \label{line:tab:onTimeoutPropose}
		\IF{$height = h_p \wedge round = round_p \wedge step_p = \propose$}
			\STATE \Broadcast \ $\li{\Prevote,h_p,round_p, \nil}$
		 	\label{line:tab:prevote-nil-on-timeout}
		 	\STATE $step_p \assign \prevote$
		 \ENDIF
		 \ENDFUNCTION

		\SHORTSPACE
		\FUNCTION{$OnTimeoutPrevote(height,round)$} \label{line:tab:onTimeoutPrevote}
		\IF{$height = h_p \wedge round = round_p \wedge step_p = \prevote$}
			\STATE \Broadcast \ $\li{\Precommit,h_p,round_p,\nil}$
			\label{line:tab:precommit-nil-onTimeout}
			\STATE $step_p \assign \precommit$
		\ENDIF
		\ENDFUNCTION

		\SHORTSPACE
		\FUNCTION{$OnTimeoutPrecommit(height,round)$} \label{line:tab:onTimeoutPrecommit}
		\IF{$height = h_p \wedge round = round_p$}
			\STATE $StartRound(round_p + 1)$ \label{line:tab:nextRound}
		\ENDIF
		\ENDFUNCTION
	\end{algorithmic} \caption{Tendermint consensus algorithm}
	\label{alg:tendermint}
\end{algorithm}

In this section we present the Tendermint Byzantine fault-tolerant consensus
algorithm. The algorithm is specified by the pseudo-code shown in
Algorithm~\ref{alg:tendermint}. We present the algorithm as a set of \emph{upon
rules} that are executed atomically\footnote{In case several rules are active
at the same time, the first rule to be executed is picked randomly. The
correctness of the algorithm does not depend on the order in which rules are
executed.}. We assume that processes exchange protocol messages using a gossip
protocol and that both sent and received messages are stored in a local message
log for every process. An upon rule is triggered once the message log contains
messages such that the corresponding condition evaluates to $\tt{true}$. The
condition that assumes reception of $X$ messages of a particular type and
content denotes reception of messages whose senders have aggregate voting power at
least equal to $X$. For example, the condition $2f+1$ $\li{\Precommit,h_p,r,id(v)}$,
evaluates to true upon reception of $\Precommit$ messages for height $h_p$,
a round $r$ and with value equal to $id(v)$ whose senders have aggregate voting
power at least equal to $2f+1$. Some of the rules ends with "for the first time" constraint
to denote that it is triggered only the first time a corresponding condition evaluates
to $\tt{true}$. This is because those rules do not always change the state of algorithm
variables so without this constraint, the algorithm could keep
executing those rules forever. The variables with index $p$ are process local state
variables, while variables without index $p$ are value placeholders. The sign
$*$ denotes any value.

We denote with $n$ the total voting power of processes in the system, and we
assume that the total voting power of faulty processes in the system is bounded
with a system parameter $f$.  The algorithm assumes that $n > 3f$, i.e., it
requires that the total voting power of faulty processes is smaller than one
third of the total voting power. For simplicity we present the algorithm for
the case $n = 3f + 1$.

The algorithm proceeds in rounds, where each round has a dedicated
\emph{proposer}. The mapping of rounds to proposers is known to all processes
and is given as a function $\coord(h, round)$, returning the proposer for
the round $round$ in the consensus instance $h$. We
assume that the proposer selection function is weighted round-robin, where
processes are rotated proportional to their voting power\footnote{A validator
with more voting power is selected more frequently, proportional to its power.
More precisely, during a sequence of rounds of size $n$, every process is
proposer in a number of rounds equal to its voting power.}.
The internal protocol state transitions are triggered by message reception and
by expiration of timeouts. There are three timeouts in Algorithm \ref{alg:tendermint}:
$\timeoutPropose$, $\timeoutPrevote$ and $\timeoutPrecommit$.
The timeouts prevent the algorithm from blocking and
waiting forever for some condition to be true, ensure that processes continuously
transition between rounds, and guarantee that eventually (after GST) communication
between correct processes is timely and reliable so they can decide.
The last role is achieved by increasing the timeouts with every new round $r$,
i.e, $timeoutX(r) = initTimeoutX + r*timeoutDelta$;
they are reset for every new height (consensus
instance).

Processes exchange the following messages in Tendermint: $\Proposal$,
$\Prevote$ and $\Precommit$. The $\Proposal$ message is used by the proposer of
the current round to suggest a potential decision value, while $\Prevote$ and
$\Precommit$ are votes for a proposed value. According to the classification of
consensus algorithms from \cite{RMS10:dsn}, Tendermint, like PBFT
\cite{CL02:tcs} and DLS \cite{DLS88:jacm}, belongs to class 3, so it requires
two voting steps (three communication exchanges in total) to decide a value.
The Tendermint consensus algorithm is designed for the blockchain context where
the value to decide is a block of transactions (ie. it is potentially quite
large, consisting of many transactions). Therefore, in the Algorithm
\ref{alg:tendermint} (similar as in \cite{CL02:tcs}) we are explicit about
sending a value (block of transactions) and a small, constant size value id (a
unique value identifier, normally a hash of the value, i.e., if $\id(v) =
\id(v')$, then $v=v'$). The $\Proposal$ message is the only one carrying the
value; $\Prevote$ and $\Precommit$ messages carry the value id.  A correct
process decides on a value $v$ in Tendermint upon receiving the $\Proposal$ for
$v$ and $2f+1$ voting-power equivalent $\Precommit$ messages for $\id(v)$ in
some round $r$. In order to send $\Precommit$ message for $v$ in a round $r$, a
correct process waits to receive the $\Proposal$ and $2f+1$ of the
corresponding $\Prevote$ messages in the round $r$. Otherwise,
it sends $\Precommit$ message with a special $\nil$ value.
This ensures that correct processes can $\Precommit$ only a
single value (or $\nil$) in a round.  As
proposers may be faulty, the proposed value is treated by correct processes as
a suggestion (it is not blindly accepted), and a correct process tells others
if it accepted the $\Proposal$ for value $v$ by sending $\Prevote$ message for
$\id(v)$; otherwise it sends $\Prevote$ message with the special $\nil$ value.

Every process maintains the following variables in the Algorithm
\ref{alg:tendermint}: $step$, $lockedValue$, $lockedRound$, $validValue$ and
$validRound$. The $step$ denotes the current state of the internal Tendermint
state machine, i.e., it reflects the stage of the algorithm execution in the
current round. The $lockedValue$ stores the most recent value (with respect to
a round number) for which a $\Precommit$ message has been sent. The
$lockedRound$ is the last round in which the process sent a $\Precommit$
message that is not $\nil$. We also say that a correct process locks a value
$v$ in a round $r$ by setting $lockedValue = v$ and $lockedRound = r$ before
sending $\Precommit$ message for $\id(v)$. As a correct process can decide a
value $v$ only if $2f+1$ $\Precommit$ messages for $\id(v)$ are received, this
implies that a possible decision value is a value that is locked by at least
$f+1$ voting power equivalent of correct processes. Therefore, any value $v$
for which $\Proposal$ and $2f+1$ of the corresponding $\Prevote$ messages are
received in some round $r$ is a \emph{possible decision} value. The role of the
$validValue$ variable is to store the most recent possible decision value; the
$validRound$ is the last round in which $validValue$ is updated. Apart from
those variables, a process also stores the current consensus instance ($h_p$,
called \emph{height} in Tendermint), and the current round number ($round_p$)
and attaches them to every message. Finally, a process also stores an array of
decisions, $decision_p$ (Tendermint assumes a sequence of consensus instances,
one for each height).

Every round starts by a proposer suggesting a value with the $\Proposal$
message (see line \ref{line:tab:send-proposal}). In the initial round of each
height, the proposer is free to chose the value to suggest. In the
Algorithm~\ref{alg:tendermint}, a correct process obtains a value to propose
using an external function    $getValue()$ that returns a valid value to
propose. In the following rounds, a correct proposer will suggest a new value
only if $validValue = \nil$; otherwise $validValue$ is proposed (see
lines~\ref{line:tab:isThereLockedValue}-\ref{line:tab:getValidValue}).
In addition to the value proposed, the $\Proposal$ message also
contains the $validRound$ so other processes are informed about the last round
in which the proposer observed $validValue$ as a possible decision value.
Note that if a correct proposer $p$ sends $validValue$ with the $validRound$ in the
$\Proposal$, this implies that the process $p$ received $\Proposal$ and the
corresponding $2f+1$ $\Prevote$ messages for $validValue$ in the round
$validRound$.
If a correct process sends $\Proposal$ message with $validValue$ ($validRound > -1$)
at time $t > GST$, by the \emph{Gossip communication} property, the
corresponding $\Proposal$ and the $\Prevote$ messages will be received by all
correct processes before time $t+\Delta$. Therefore, all correct processes will
be able to verify the correctness of the suggested value as it is supported by
the $\Proposal$ and the corresponding $2f+1$ voting power equivalent $\Prevote$
messages.

A correct process $p$ accepts the proposal for a value $v$  (send $\Prevote$
for $id(v)$) if an external \emph{valid} function returns $true$ for the value
$v$, and if $p$ hasn't locked any value ($lockedRound = -1$) or $p$ has locked
the value $v$ ($lockedValue = v$); see the line
\ref{line:tab:accept-proposal-2}.  In case the proposed pair is $(v,vr \ge 0)$ and a
correct process $p$ has locked some value, it will accept
$v$ if it is a more recent possible decision value\footnote{As
explained above, the possible decision value in a round $r$ is the one for
which $\Proposal$ and the corresponding $2f+1$ $\Prevote$ messages are received
for the round $r$.}, $vr > lockedRound_p$,  or if $lockedValue = v$
(see line~\ref{line:tab:cond-prevote-higher-proposal}).  Otherwise, a correct
process will reject the proposal by sending $\Prevote$ message with $\nil$
value. A correct process will send $\Prevote$ message with $\nil$ value also in
case $\timeoutPropose$ expired (it is triggered when a correct process starts a
new round) and a process has not sent $\Prevote$ message in the current round
yet (see the line \ref{line:tab:onTimeoutPropose}).

If a correct process receives $\Proposal$ message for some value $v$ and $2f+1$
$\Prevote$ messages for $\id(v)$, then it sends $\Precommit$ message with
$\id(v)$. Otherwise, it sends $\Precommit$ $\nil$. A correct process will send
$\Precommit$ message with $\nil$ value also in case $\timeoutPrevote$ expired
(it is started when a correct process sent $\Prevote$ message and received any
$2f+1$ $\Prevote$ messages)  and a process has not sent $\Precommit$ message in
the current round yet (see the line \ref{line:tab:onTimeoutPrecommit}).  A
correct process decides on some value $v$ if it receives in some round $r$
$\Proposal$ message for $v$ and $2f+1$ $\Precommit$ messages with $\id(v)$ (see
the line \ref{line:tab:decide}).  To prevent the algorithm from blocking and
waiting forever for this condition to be true, the Algorithm
\ref{alg:tendermint} relies on $\timeoutPrecommit$. It is triggered after a
process receives any set of $2f+1$ $\Precommit$ messages for the current round.
If the $\timeoutPrecommit$ expires and a process has not decided yet, the
process starts the next round (see the line \ref{line:tab:onTimeoutPrecommit}).
When a correct process $p$ decides, it starts the next consensus instance
(for the next height). The \emph{Gossip communication} property ensures
that $\Proposal$ and $2f+1$ $\Prevote$ messages that led $p$ to decide
are eventually received by all correct processes, so they will also decide.

\subsection{Termination mechanism}

Tendermint ensures termination by a novel mechanism that benefits from the
gossip based nature of communication (see \emph{Gossip communication}
property).  It requires managing two additional variables, $validValue$ and
$validRound$ that are then used by the proposer during the propose step as
explained above.   The $validValue$ and $validRound$ are updated to $v$ and $r$
by a correct process in a round $r$ when the process receives valid $\Proposal$
message for the value $v$ and the corresponding $2f+1$ $\Prevote$ messages for
$id(v)$ in the round $r$ (see the rule at line~\ref{line:tab:recvPrevote}).

We now give briefly the intuition how managing and proposing $validValue$
and $validRound$ ensures termination. Formal treatment is left for
Section~\ref{sec:proof}.

The first thing to note is that during good period, because of the
\emph{Gossip communication} property, if a correct process $p$ locks a value
$v$ in some round $r$, all correct processes will update $validValue$ to $v$
and $validRound$ to $r$ before the end of the round $r$ (we prove this formally
in the Section~\ref{sec:proof}). The intuition is that messages that led to $p$
locking a value $v$ in the round $r$ will be gossiped to all correct processes
before the end of the round $r$, so it will update $validValue$ and
$validRound$ (the line~\ref{line:tab:recvPrevote}). Therefore, if a correct
process locks some value during good period, $validValue$ and $validRound$ are
updated by all correct processes so that the value proposed in the following
rounds will be acceptable by all correct processes. Note
that it could happen that during good period, no correct process locks a value,
but some correct process $q$ updates $validValue$ and $validRound$ during some
round. As no correct process locks a value in this case, $validValue_q$ and
$validRound_q$ will also be acceptable by all correct processes as
$validRound_q > lockedRound_c$ for every correct process $c$ and as the
\emph{Gossip communication} property ensures that the corresponding $\Prevote$
messages that $q$ received in the round $validRound_q$ are received by all
correct processes $\Delta$ time later.

Finally, it could happen that after GST, there is a long sequence of rounds in which
no correct process neither locks a value nor update $validValue$ and $validRound$.
In this case, during this sequence of rounds, the proposed value suggested by correct
processes was not accepted by all correct processes. Note that this sequence of rounds
is always finite as at the beginning of every
round there is at least a single correct process $c$ such that $validValue_c$
and $validRound_c$ are acceptable by every correct process. This is true as
there exists a correct process $c$ such that for every other correct process
$p$, $validRound_c > lockedRound_p$ or $validValue_c = lockedValue_p$. This is
true as $c$ is the process that has locked a value in the most recent round
among all correct processes (or no correct process locked any value). Therefore,
eventually $c$ will be the proper in some round and the proposed value will be accepted
by all correct processes, terminating therefore this sequence of
rounds.

Therefore, updating $validValue$ and $validRound$ variables, and the
\emph{Gossip communication} property, together ensures that eventually, during
the good period, there exists a round with a correct proposer whose proposed
value will be accepted by all correct processes, and all correct processes will
terminate in that round. Note that this mechanism, contrary to the common
termination mechanism illustrated in the
Figure~\ref{ch3:fig:coordinator-change}, does not require exchanging any
additional information in addition to messages already sent as part of what is
normally being called "normal" case.


\documentclass{beamer}
\usepackage{csquotes}
\usepackage{tikz}
\usetikzlibrary{arrows,positioning,shapes.geometric, calc}
\usepackage{amsmath}
\usepackage{listings, xcolor}
\usepackage{lmodern}
\usepackage{adjustbox}
\usepackage{booktabs}
\usepackage{colortbl}
\usepackage{caption}
\usepackage{icomma}
\usepackage{bigstrut}
\usepackage{geometry}
\usepackage{subfigure}
\usepackage{algorithmic}

\DeclareMathOperator*{\argmin}{argmin}
\captionsetup[figure]{labelformat=empty}

\usetheme{metropolis}           % Use metropolis theme
\title{Update: NN project}
\date{\today}
\author{Robert M. Porsch}
\institute{Center for Genomic Science}
\begin{document}
\maketitle

\begin{frame}[t]{Training, Development, Testing}
  \begin{columns}[t]
    \begin{column}{0.5\textwidth}
      Simulation Data 1:\\
      \begin{itemize}
        \item $\sim2,000$ samples
        \item 40 different simulated phenotypes
        \item based on 1000 Genome project
        \item $MAF\geq1\%$
      \end{itemize}
    \end{column}
    \begin{column}{0.5\textwidth}
     Simulation Data 2:
     \begin{itemize}
       \item $\sim300,000$ samples
       \item 4 different simulated phenotypes
       \item based on UKB
        \item $MAF\geq1\%$
     \end{itemize}
    \end{column}
  \end{columns}
  Issues: sample size limitations for development/testing dataset
\end{frame}

\begin{frame}[t]{On the issue of clumping}
  \begin{itemize}
    \item Clumping can be seen as a variable selection methods (with the parameter p1, p2, r2 and window size)
    \item Tests for a linear relationship between SNP and phenotype
  \end{itemize}
  So when is this becoming a problem?
  \begin{itemize}
    \item nonlinearity
    \item interactions
    \item additional hypterparameter to optimize
  \end{itemize}
\end{frame}

\begin{frame}[t]{On the sucess of clumping}
  \begin{columns}
    \begin{column}{0.5\textwidth}
      \begin{figure}[htpb]
        \centering
        \includegraphics[width=0.8\linewidth]{./clumped_1kg_lasso.png}
        \caption{Clumped Lassosum}
      \end{figure}
    \end{column}
    \begin{column}{0.5\textwidth}
      \begin{figure}[htpb]
        \centering
        \includegraphics[width=0.8\linewidth]{./not_clumped_1kg_lasso.png}
        \caption{NOT Clumped Lassosum}
      \end{figure}
    \end{column}
  \end{columns}
\end{frame}

\begin{frame}[t]{NN are difficult to fit}
  \begin{columns}
    \begin{column}{0.5\textwidth}
      \begin{figure}[htpb]
        \centering
        \includegraphics[width=0.8\linewidth]{keras_model_ukb_nn}
        \caption{Complex model (85,60,60,60)}
      \end{figure}
    \end{column}
    \begin{column}{0.5\textwidth}
      \begin{figure}[htpb]
        \centering
        \includegraphics[width=0.8\linewidth]{keras_model_ukb_nn_small}
        \caption{Simple model (60)}
      \end{figure}
    \end{column}
  \end{columns}
  \begin{itemize}
    \item Complexity becomes difficult to train (learning rate)
    \item The phenotype is linear
  \end{itemize}
\end{frame}

\begin{frame}[t]{Sometimes you need to think}
  \begin{columns}
    \begin{column}{0.5\textwidth}
      \begin{figure}[htpb]
        \centering
        \includegraphics[width=0.8\linewidth]{keras_model_ukb_linear.png}
        \caption{Linear Model on the UKB}
      \end{figure}
    \end{column}
    \begin{column}{0.5\textwidth}
      \begin{figure}[htpb]
        \centering
        \includegraphics[width=0.8\linewidth]{./keras_model_ukb_nn_small.png}
        \caption{Small NN model on the UKB}
      \end{figure}
    \end{column}
  \end{columns}
  \begin{itemize}
    \item Drop out layer regularizes efficiently
    \item During validation dropout is deactivated
  \end{itemize}
\end{frame}

\begin{frame}[t]{On Sample Size}
  \begin{columns}
    \begin{column}{0.5\textwidth}
      \begin{figure}[htpb]
        \centering
        \includegraphics[width=0.8\linewidth]{./keras_model_ukb_nn_small.png}
        \caption{Small NN model on the UKB}
      \end{figure}
    \end{column}
    \begin{column}{0.5\textwidth}
      \begin{figure}[htpb]
        \centering
        \includegraphics[width=0.8\linewidth]{./keras_model_1kg_nn_small.png}
        \caption{Small NN model on the 1KG}
      \end{figure}
    \end{column}
  \end{columns}
  \begin{itemize}
    \item less overfitting
    \item results remain accurate despite low sample size
  \end{itemize}
\end{frame}

\begin{frame}[t]{Evaluation}
  \begin{itemize}
    \item Trivial problem given a linear simulated phenotype
    \item Now-complexity
  \end{itemize}
\end{frame}

% \begin{frame}[t]{UKB Data}
%   I also made use of the UKB with the following phenotypes:
%   \begin{itemize}
%     \item height
%     \item IQ
%   \end{itemize}
%   Data was split into training and dev set using caucsian samples only.
%   Dev set was set to be at least $10,000$ samples.
%
%   Some potential problems with the data structure:
%   \begin{itemize}
%     \item data was not shuffled
%     \item currently data was not adjusted for potential confounders (unclear how important)
%   \end{itemize}
% \end{frame}
%
% \section{Fully connected LD Layer: FullDa}
%
% \begin{frame}[t]{Architecture}
%   \begin{columns}[t]
%     \begin{column}{0.5\textwidth}
%       Layer 1:
%       \begin{algorithmic}
%         \STATE initialize $Z$
%         \FOR{v = LD-Blocks}
%         \STATE $z_v = W^{[1]}_vX_v$
%         \STATE $a_v = g(z_v)$
%         \STATE $APPEND(Z, z_v)$
%         \ENDFOR
%       \end{algorithmic}
%       Layer $2$:\\
%       \begin{itemize}
%         \item fully connected layers to output
%         \item $L_1$ regularization in $l=1,2$
%         \item dropout with $p=0.8$
%       \end{itemize}
%     \end{column}
%     \begin{column}{0.5\textwidth}
%       Optimization:
%       \begin{itemize}
%         \item AdaGrad
%         \item Mini-Batch gradient decent with $m=100$
%         \item no early stopping ($epochs=100$)
%       \end{itemize}
%     \end{column}
%   \end{columns}
% \end{frame}
%
% \begin{frame}[t]{Model Overview}
%   \begin{figure}[htpb]
%     \centering
%     \includegraphics[width=0.8\linewidth]{./tensormodel.png}
%   \end{figure}
% \end{frame}
%
% \begin{frame}[t]{Some results}
%   \begin{figure}[htpb]
%     \centering
%     \includegraphics[width=0.8\linewidth]{performance.png}
%     \caption{Example performance on phenotype 1}
%   \end{figure}
%   \begin{itemize}
%     \item high variance problem
%     \item disappointing performance in development set
%     \item performance similar to LassoSum
%   \end{itemize}
% \end{frame}
%
% \section{Clumped NN}
%
% \begin{frame}[t]{Architecture}
%   Similar architecture but with additional clumping step
%
%   \begin{enumerate}[(i)]
%     \item run GWAS on training set
%     \item perform clumping ($r^2=0.5, p_1 = 0.01, p_2 = 0.1$)
%       \begin{itemize}
%         \item Results in 72 SNPs
%       \end{itemize}
%     \item feed clumped genotype matrix into fully connected NN $L=3$
%       \begin{itemize}
%         \item $n^{[1]}_h=60, n^{[2]}_h=60, n^{[3]}_h=1$
%         \item dropout layer after $l=1$ and $l=2$
%       \end{itemize}
%   \end{enumerate}
%   No early stopping, ($epochs=100$), mini-batch with $m=100$
% \end{frame}
%
% \begin{frame}[t]{Results}
%   \begin{figure}[htpb]
%     \centering
%     \includegraphics[width=0.8\linewidth]{./keras_model.png}
%   \end{figure}
%   \begin{itemize}
%     \item Similar performance to the LD-connected NN
%     \item high variance problem
%   \end{itemize}
% \end{frame}
%
% \begin{frame}[t]{Conclusions}
%   \begin{itemize}
%     \item Stronger regularization is required
%     \item Currently there is no hyper-parameter optimization
%     \item Larger dataset should be used (requires some re-write of the data import)
%     \item Current literature: More and more paper on penalized regression for genetic risk prediction (mostly Lasso)
%   \end{itemize}
% \end{frame}
\end{document}


%!TEX root = morusAC.tex

\section{Introduction}
\label{sec/Introduction}

Authenticated Encryption (AE) schemes combine the functionality of symmetric encryption schemes and message authentication codes.
Based on a shared secret key $K$, they encrypt a plaintext message $M$ to a ciphertext $C$ and authentication tag $T$ in order to protect both the confidentiality and the authenticity of $M$.
Most modern authenticated encryption algorithms are nonce-based schemes with associated data (AEAD),
where $(C, T)$ additionally depends on a unique nonce $N$ (or initialization value IV) and optional associated metadata $A$.
One of the most prominent standardized AEAD designs is \cipher{AES-GCM} \cite{indocryptMcGrewV04,nistDworkin07},
which is widely deployed in protocols such as \cipher{TLS} (since v1.2).

To address the growing need for modern authenticated encryption designs for different application scenarios,
the CAESAR competition was launched in 2013 \cite{CAESAR}.
The goal of this competition is to select a final portfolio of AEAD designs for three different use-cases:
(1) lightweight hardware characteristics,
(2) high-speed software performance, and
(3) robustness.
The competition attracted 57 first-round submissions, 7 of which were recently selected as finalists in the fourth selection round.

\MORUS is one of the three finalists for use-case (2), together with \cipher{OCB} and \cipher{AEGIS}.
This family of authenticated ciphers by Wu and Huang \cite{MORUS} provides three main variants:
\MORUS[640] with a 128-bit key and \MORUS[1280] with either a 128-bit or a 256-bit key.
The design approach is reminiscent of classical stream cipher designs and
continuously updates a relatively large state with a few fast operations.
\MORUS can be efficiently implemented in both software and hardware;
in particular, the designers claim that the software performance even surpasses
\cipher{AES-GCM} implementations using Intel's \cipher{AES-NI} instructions,
and that \MORUS is the fastest authenticated cipher not using \cipher{AES-NI} \cite{MORUS}.

\subsubsection*{Related Work.}
In the \MORUS submission document, the designers discuss the security of \MORUS against
several attacks, including algebraic, differential, and guess-and-determine attacks.
The main focus is on differential properties, and not many details are given for other attack vectors.
In third-party analysis,
Mileva et~al.~\cite{balkancryptsecMilevaDV15} propose a distinguisher in the nonce-reuse setting and practically evaluate the differential behaviour of toy variants of \MORUS.
Shi et~al.~\cite{aiieShiGLZ16} analyze the differential properties of the finalization reduced to 2 out of 10 steps, but find no attacks.
Dwivedi et~al.~\cite{cryptoeprint:2016:1053} discuss the applicability of SAT solvers for state recovery, but the resulting complexity of $2^{370}$ for \MORUS[640] is well beyond the security claim.
Dwivedi et~al.~\cite{secryptDwivediMW17} also propose key-recovery attacks for \MORUS[1280] if initialization is reduced to 3.6 out of 16 steps, and discuss the security of \MORUS against internal differentials and rotational cryptanalysis.
Salam et~al.~\cite{trustcomSalamSBDPW17} apply cube attacks to obtain distinguishers for up to 5 out of 16 steps of the initialization of \MORUS[1280] with negligible complexity.
Additionally,
Kales et~al.~\cite{cryptoeprint:2017:1137} and
Vaudenay and Viz\'{a}r \cite{cryptoeprint:2017:1147}
independently propose state-recovery and forgery attacks on \MORUS in a nonce-misuse setting with negligible data and time complexities.

Finally, a keystream correlation similar in nature to our main attack was uncovered by Minaud \cite{sacryptMinaud14} on the authenticated cipher \cipher{AEGIS} \cite{AEGIS,sacryptWuP13}, another CAESAR finalist.
\cipher{AEGIS} shares the same overall structure as \MORUS, but uses a very different state update function,
based on the parallel application of \cipher{AES} rounds, rather than the shift/AND/XOR operations used in \MORUS.
Similar to our attack, the approach in \cite{sacryptMinaud14} is to build a linear trail linking ciphertext bits, while canceling the
contribution of inner state bits.
How the trail is built depends primarily on the state update function, and how it lends itself to linear cryptanalysis.
Because the state update function differs significantly between AEGIS and MORUS, the process used to build the trail is also quite different.

\subsubsection*{Our Contributions.}
Our main contribution is a keystream distinguisher on full \MORUS[1280], built from linear approximations of its core \StateUpdate{} function.
In addition, we provide results for round-reduced \MORUS, targeting both the initialization or finalization phases of the cipher.

In more detail, our main result is a linear approximation \cite{eurocryptMatsui93,eurocryptMatsuiY92} linking plaintext and ciphertext bits spanning five consecutive encryption blocks.
%As a consequence of this trail, we exhibit a biased linear combination of ciphertext bits, which holds across any given sequence of five consecutive encryption steps.
%Technically, this assumes that the inner state of the cipher at the start of the trail is uniformly random, but this is a fair assumption since the inner state should be indistinguishable from uniform randomness by design.
%Moreover, that is the only assumption required; in particular, the secret key or the nonce used to initialize the inner state of MORUS are irrelevant: the bias is independent of their value.
%As a consequence, when encrypting a fixed plaintext segment multiple times, a linear correlation exists between some output bits of the cipher.
Moreover, the correlation does not depend on the secret key of the cipher.
In principle, this property could be used as a known-plaintext distinguisher, or to recover unknown bits of a plaintext encrypted a large number of times.
For \MORUS[1280] with 256-bit keys, the linear correlation is $2^{-76}$
and can be exploited using about $2^{152}$ encrypted blocks.

To the best of our knowledge, this is the first attack on full \MORUS in the nonce-respecting setting.
We note that rekeying does not prevent the attack: the biases are independent of the secret encryption key and nonce, and can be exploited for plaintext recovery as long as a given plaintext segment is encrypted sufficiently often, regardless of whether each encryption uses a different key.
A notable feature of the linear trail underpinning our attack is also that it does not depend on the values of rotation constants: a very similar trail would exist for most choices of round constants.

To obtain this result, we propose a simplified abstraction of \MORUS, called \MiniMORUS. \MiniMORUS takes advantage of certain rotational invariants in \MORUS and simplifies the description and analysis of the attack. We then show how the attack can be extended from \MiniMORUS to the real \MORUS.
%We observe that the actual bias of the approximation is better than suggested by the construction of the characteristics.
To confirm the validity of our analysis,
we practically verified the correlation of the full linear trail for \MiniMORUS, as well as the correlation of trail fragments for the full \MORUS.
Our analysis is also backed by a symbolic evaluation of the full trail equation and its correlation on all variants of \MORUS.

In addition to the previous attack on full \MORUS, we provide two secondary results: (1) we analyze the security of \MORUS against forgery attacks with round-reduced finalization; and (2) we analyze its security against key recovery in a nonce-misuse setting, with round-reduced initialization.
While this extra analysis does not threaten full \MORUS, it complements the main result to provide a better overall understanding of the security of \MORUS.
More precisely, we present a forgery attack for round-reduced \MORUS[1280] with success probability $2^{-88}$ for a 128-bit tag if the finalization is reduced to 3 out of 10 steps. This nonce-respecting attack is based on a differential analysis of the padding rule.
The second result targets round-reduced initialization with 10 out of 16 steps, and extends a state-recovery attack (which can be mounted e.g. in a nonce-misuse setting) into a key-recovery attack.

\subsubsection*{Outline.}
This paper is organized as follows.
We first provide a brief description of \MORUS in \Cref{sec/Preliminaries}.
In \Cref{sec/introminimorus}, we introduce \MiniMORUS, an abstraction of \MORUS based on a certain class of rotational invariants.
We analyze this simplified scheme in \Cref{sec/minitrails} and provide a ciphertext-only linear approximation with a weight of 16.
We then extend our result to the full scheme in \Cref{sec/fulltrails}, showing a correlation in the keystream over 5 steps,
and discuss the implications of our observation for the security of \MORUS in \Cref{sec/Discussion}.
In \Cref{sec/IniFin}, we present our results on the security of \MORUS with round-reduced initialization (in a nonce-misuse setting) or finalization.
We conclude in \Cref{sec/Conclusion}.

%%% Local Variables:
%%% TeX-master: "morusAC"
%%% End:


% !TEX root =  main.tex

To establish an authenticated security context for \mOscore,
\mEdhoc{} uses a three-message protocol structure
shown in Figure~\ref{fig:edhocFramework}.
%
In the first message \mMsgone{}, the initiator (\mT{I}) sends to the responder (\mT{R}) an
ephemeral DH half-key \mGx{}, an ordered list of supported cipher suites, and, in the \mMethod{} element, suggests
authentication methods to be used.
%
\mT{R} may reject the choice of cipher suite, leading to a negotiation across multiple \mEdhoc{} sessions (see Section~\ref{sec:ciphersuiteNegotiation}), or that of the authentication methods.
%
In the second message \mMsgtwo{}, \mT{R} provides its ephemeral
DH half-key \mGy{} and authenticates itself to \mT{I} by
providing authentication data \mAuthr{}.
%
Finally, in the third message \mMsgthree{}, \mT{I} authenticates itself
to \mT{R} by providing authentication data \mAuthi{}.
%
The authentication data consists of a MAC for all authentication methods.
%
This MAC is also signed when authentication is based on public key signatures.
%
In addition to the exchange of DH half-keys and authentication data, the
messages also include parameters for the \mOscore{} security context, such as
encryption algorithm identifiers (\mSuites{}) and \mOscore{} security context
identifiers \mCi{} and \mCr{}.
%
Optionally, messages may also include application layer data \mAD{}, which
enjoys differing levels of protection depending on which message it is part of.
%
We do not include \mCi, \mCr, and \mAD{} in our modelling here.
%
When authentication is based on
a pre-shared key, the \mCredi{} and \mCredr{} credential identifiers are not
used.
%
Instead, a single identifier for the pre-shared key is transmitted in \mMsgone{}.
%
\begin{figure}
\centering
\linespread{1}
\tikzset{>=latex, every msg/.style={draw=thick}, every node/.style={fill=none,text=black}}
\begin{tikzpicture}
    \node (ini) at (0, 0) {Initiator (\mT{I})};
    \draw [very thick] (0, -0.25) -- (0,-2.2);
    \draw [very thick] (7, -0.25) -- (7,-2.2);
    \node (res) at (7,0) {Responder (\mT{R})};
    \msg{1em}{ini}{res}{\mMsgone: \mMethod, \mSuites, \mGx, \mCi, \mADone};
\msg{3em}{res}{ini}{\mMsgtwo: \mCi, \mGy, \mCr, [\mIdcredr, \mAuthr, \mADtwo]};
    \msg{5em}{ini}{res}{\mMsgthree: \mCr, [\mIdcredi, \mAuthi, \mADthree]};
    \draw [line width=1mm] (-0.75,-2.2) -- (0.75,-2.2);
    \draw [line width=1mm] (7-0.75,-2.2) -- (7+0.75,-2.2);
    \end{tikzpicture}
\caption{Structure of \mEdhoc{}: $[t]$ means $t$ is encrypted and integrity protected}
\label{fig:edhocFramework}
\end{figure}

\knote{note that the version we look at has private keys, but the current spec
    in IETF does not. OTOH, they aim to add that later, and I can't see how they
    could avoid doing so. That is why I write "aims to..."
}
\mEdhoc{} aims to accommodate three credential types
a party may use for authentication -- certificates, private keys
and static long-term DH keys.
%
Depending on the types used, the authentication methods differ,
and \mAuthi{} and \mAuthr{} need to be constructed accordingly.
%
The three authentication methods are based on digital signatures (\mSig),
challenge-response signatures based on static long-term DH keys (\mStat) and
pre-shared symmetric keys (\mPsk).
%
The two parties may use different authentication methods in an \mEdhoc{} run.
%
While any combination of the \mSig{} and \mStat{} methods is possible,
when \mPsk{} is used, both parties must use \mPsk{}.
%
We refer to these \emph{combinations} of authentication methods as
\emph{methods} to follow the terminology in the
\mSpec{}~\cite{selander-lake-edhoc-01}.
%
Thus, we have five methods: \mSigSig, \mSigStat, \mStatStat, \mStatSig{} and
\mPskPsk.
%
The first method in a name denotes the
authentication method used by the initiator of the protocol run and the second denotes the
one used by the responder.
%
We refer to a method where at least one party uses \mSig{} as a \mSig-based
method, and similarly for \mStat{} and \mPsk.
%

We first briefly discuss \mEdhoc's relations to the protocols on which it is
based before providing details about the methods.
%

%-----------------------------------------------------------------------------
\subsection{Relation to \mSigma, \mOptls{}, and \mNoise{}}
\label{sec:relationsToOtherProtocols}
We now present how \mEdhoc{} uses \mSigma, \mOptls{}, and \mNoise{} as
cryptographic cores for various methods, and the ways in which it differs from them.
\\
%
Being designed as an industrial standard, \mEdhoc{} specifies more details
on top of these cores, e.g., connection identifiers for message multiplexing,
encoding and application specific parameters to be negotiated.
%

%-----------------------------------------------------------------------------
%\runhead{\mSigma{}}
\subsubsection{\mSigma{}}
\label{sec:sigma}
The \mSigSig{} method of \mEdhoc{} is closely modeled on the \mSigma{}
variant that provides identity protection for the initiator~\cite{sigma}.
%
Some aspects differ though, e.g., \mSigSig{} uses Mac-then-Sign like
\mTls{} instead of Sign-then-Mac.
%

%-----------------------------------------------------------------------------
\subsubsection{\mOptls{}}
\label{sec:optls}
The \mStat-based methods use challenge-response signatures based on static
long-term DH keys, and proceed along the lines of
\mOptls~\cite{DBLP:conf/eurosp/KrawczykW16}.
%
The challenge-response works as follows.
Party $A$ sends a random challenge $r$
and an ephemeral DH half-key $e$ to a party $B$.
%
$B$ mixes $e$ and $r$ with its secret static
long-term DH key $s$ to obtain a temporary key, which
%
is used to compute a MAC that is returned to $A$.
%
This authenticates $B$ to $A$, which is sufficient for \mOptls,
because it only considers server authentication, where the server acts as $B$
and the client as $A$.
%
The temporary key also affects the final session key.
%

In \mEdhoc, a party using the \mStat{} authentication method
essentially acts as an \mOptls{} client and the peer as an \mOptls{}
server.
%
However, unlike \mOptls{}, \mEdhoc{} requires mutual
authentication~\cite{ietf-lake-reqs-04}.
%
\mStatStat{} can be thought of as interleaving two \mOptls{}
runs, one initiated by each party, and then combining the resulting session key
material.
%
Also, \mOptls{} uses the conservative security approach where $e$ and $r$
are distinct elements, whereas \mEdhoc{} reuses the $e$ as the challenge $r$.
%
The latter can only weaken security.
%

%------------------------------------------------------------------------- sub
\subsubsection{\mNoise{}}
The \mStatStat{} and \mPskPsk{} methods follow the \mNoise{}
framework~\cite{perrin2016noise}.
%
\mNoise{} defines how to construct AKE protocols, using static long-term DH
keys or pre-shared keys as credentials.
%
Its goal is to use so-called patterns to harmonize the many static long-term
key DH-based AKE protocols, of which \mOptls{} is one.
%
\mNoise{} specifies how to derive keys, use transcript hashes to ensure
authentication of the message flow etc.
%
The \mNoise{} pattern closest to the \mStatStat{} method is called XX.
%
However, \mEdhoc{} does not use the functions of \mNoise{} exactly as
prescribed.
%
It is thus not obvious that \mEdhoc{} automatically inherits
the properties enjoyed by XX.
%
For example, according to \mNoise{}, the mixHash function is called on
pre-message public keys during the initialization.
%
This would correspond to \mEdhoc{} computing a first intermediate transcript
hash over those keys, which \mEdhoc{} does not do.
%

%------------------------------------------------------------------------- sub
\subsection{Methods of \mEdhoc{}}
\label{sec:methods}
Although \mCbor{} and \mCose{}~\cite{rfc8152} are important building blocks of
\mEdhoc{}, and we use their terminology in our \mTamarin{} model to better
reflect the \mSpec{}, our model does not cover the details of encoding and
\mCose{} interfaces.
%
Thus, we omit details about \mCbor{} and \mCose{}. Similarly, we refer the reader to~\cite{aead} for details about authenticated encryption with associated data (AEAD).
%
All methods make use of a common key hierarchy, which we describe first.
%

%------------------------------------------------------------------------- sub
\subsubsection{Key Hierarchy}
%\runhead{Key Hierarchy}
\label{sec:keyHierarchy}
\mEdhoc{} derives keys using \mHkdf{}~\cite{rfc5869}.
%
The \mHkdf{} interface provides two functions -- \mHkdfExtract{}, which
constructs uniformly distributed key material from random input and a seed,
and \mHkdfExpand{}, which generates keys from key material and a seed.
%
The seeds are used to bind the key material and keys to certain parameters.
%
Derived keys (\mKtwoe, \mKtwom{}, \mKthreeae, and \mKthreem) are then used as
input to encryption and integrity protection algorithms.
%

The key hierarchy is rooted in the ephemeral DH key \mGxy{}, the combination
of the two half-keys \mGx{} and \mGy{}.
%
From this, keys are successively constructed with each transmitted message,
weaving in information parties learn as the protocol progresses, culminating
in the established session key material.
%
From the session key material, a key exporter (\mEdhoc-Exporter) based on
\mHkdf{} can be used to extract the encryption and integrity keys required
for \mOscore{}.
%
Figure~\ref{fig:kdfdiagram} shows an abstract description of the key hierarchy.
%

From \mGxy{}, three intermediate keys \mPRKtwo, \mPRKthree{} and
\mPRKthree{} are derived.
%
Each one of them corresponds to a specific message in the protocol, and from
these intermediate keys, encryption and integrity keys for that message are
derived.
%
For \mPskPsk{}, the pre-shared key is used as seed for \mPRKtwo.
%
For all other methods the seed for \mPRKtwo{} is empty.
%
In the \mPskPsk{} and \mSigSig{} methods, all three intermediate keys
are the same, i.e., $\mPRKtwo{} = \mPRKthree{} = \mPRKfour$.
%
For the three \mStat-based methods, however, they differ.
%
This is because the intermediate key \mPRKthree{} is dependent on the static
long-term key of the party (or parties, if both) using \mStat{}-based
authentication.
%

\begin{figure}[!h]
\centering
\scalebox{.75}{
\linespread{1}
\input{kdfdiagram.tex}
}
\caption{Joint key hierarchy for all methods}
\label{fig:kdfdiagram}
\end{figure}

We now describe the \mEdhoc{} methods.
%
%Since the \mSigSig{} method has been analyzed earlier, we do not focus on
%it here.
%

\subsubsection{\mPskPsk{}}
In this method, the initiator and responder are assumed to share a pre-shared
key (\mPsk) identified by \mIDPsk.
%
The message sequence is shown in Figure~\ref{fig:edhocpsk}.
%
The first message contains the \mIDPsk{} identifier.
%
The responder obtains the corresponding \mPsk{} and uses that to construct the
authentication data, i.e., the MAC in the \mAead{} transform), included in
the second message.
%
n the third message, the initiator uses this same technique to authenticate
to the responder.
%
The transcript hash \mTH{} keeps track of the data sent in the messages.
%
One unconventional feature is that the transcript hash lags behind by one
message.
%
That is, the second transcript hash \mTHtwo{}, does not cover the content of
the second message (similarly for \mTHthree).
%
The reason for this is that \mTHtwo{} cannot cover the output of the
\mAead{} transform, since \mTHtwo{} is itself an input to it.
%
This is the same for all methods, but it does not cause any problems with
authentication, since the data not covered by the transcript hash is
instead MACed or signed.
%

\begin{figure}
\centering
\linespread{1}
\scalebox{.69}{
\tikzset{>=latex, every msg/.style={draw=thick}, every node/.style={fill=none,text=black}}
\begin{tikzpicture}
    \node (ini) at (0, 0) {Initiator};
    \draw [very thick] (0, -0.5) -- (0,-11);
    \draw [very thick] (11.5, -0.5) -- (11.5,-11);
    \node[below=0.5em of ini,fill=white] () {Knows $g,\ \mPsk,\ \mIDPsk,\ \mADone,\ \mADthree$};
    \node (res) at (11.5,0) {Responder};
    \node[below=0.5em of res,fill=white] () {Knows $g,\ \mPsk,\ \mIDPsk,\ \mADtwo$};
    \action{3em}{ini}{Generates \mMethod,\ \mSuites,\ \mCi,\ $x$\\$\mGx = g^{x}$};
    \msg{6.5em}{ini}{res}{\mMsgone: \mMethod, \mSuites, \mGx, \mCi, \mIDPsk, \mADone};
    \action{7em}{res}{$
      \begin{array}{c}
        \text{Generates } \mCr,\ $y$\\
        \mGy = g^{y}\\
        \mTHtwo = \mHash(\mMsgone, g^{y})\\
        \mPRKtwo = \mHkdfExtract(\mPsk, g^{xy}) \\
        \mKtwoae = \mHkdfExpand(\mPRKtwo, \mTHtwo)
      \end{array}$};
    \msg{15.5em}{res}{ini}{\mMsgtwo: \mCi, \mGy, \mCr, $\overbrace{\mAead(\mKtwoae; \mTHtwo, \mADtwo)}^{\mCipher}$};
    \action{16.5em}{ini}{$
      \begin{array}{c}
       \mTHtwo = \mHash(\mMsgone, \mGy)\\
       \mPRKtwo = \mHkdfExtract(\mPsk, g^{xy}) \\
        \mKtwoae = \mHkdf(\mPRKtwo, \mTHtwo)\\
        \mTHthree = \mHash(\mTHtwo, \mCipher)\\
        \mPRKthree = \mPRKtwo \\
        \mKthreeae = \mHkdfExpand(\mPRKthree, \mTHthree)
      \end{array}$};

    \msg{25.5em}{ini}{res}{\mMsgthree: \mCr, \mAead(\mKthreeae; \mTHthree; \mADthree)};
    \action{26em}{res}{$
    \begin{array}{c}
    	\mPRKthree = \mPRKtwo \\
        \mKthreeae = \mHkdfExpand(\mPRKthree, \mTHthree)
    \end{array}$};
    \draw [line width=1mm] (-2,-11) -- (2,-11);
    \draw [line width=1mm] (9.5,-11) -- (13.5,-11);
    \end{tikzpicture}}
\caption{The \mPskPsk{} method; $\mAead(k; x; y)$ is used to denote
\mAead{} encryption where $k$ is the key, $x$ is associated data to be integrity
protected, and $y$ is the plaintext}
\label{fig:edhocpsk}
\end{figure}
%

%------------------------------------------------------------------------- sub
\subsubsection{\mStat-based Methods.}
\mEdhoc{} provides three \mStat-based methods -- \mSigStat{}, \mStatStat{} and
\mStatSig{}.
%
One or both of the initiator and responder authenticate to their peer using
their secret static long-term DH key, \mLtki{} or \mLtkr{} respectively.
%
Authentication of the party using the \mStat{} method follows the
challenge-response signature pattern from \mOptls.
%
In the same terms as Section~\ref{sec:optls}, the ephemeral DH half-key of the
peer takes the place of both $r$ and $e$, i.e., $r=e$, and $s$ is the secret
static long-term DH key of the party to be authenticated.
%
Assuming the discrete log problem is hard in the underlying DH group,
only the initiator and responder will be able to compute $e^s$.
%
That value is then affecting the computation of \mAuthr{} or \mAuthi{}
(depending on who is the authenticator), and it is also
woven in to the key hierarchy, see
Figures~\ref{fig:kdfdiagram} and \ref{fig:edhocsigstat}.
%
The receiver of \mAuthi{}/\mAuthr{} assumes that only the responder knows
the corresponding $e^s$, and therefore considers the peer authenticated if
the \mAead{} transform completes successfully.\\
%
In contrast to the \mPskPsk{} method, in \mStat{}-based methods, each party provides an identifier, \mIdcredi{} and \mIdcredr{} respectively, for the credentials they use.
%

%------------------------------------------------------------------------- sub
%\subsubsection{\mSigStat.}
\paragraph{\mSigStat}
The initiator uses the \mSig{} method, authenticating with a signature,
while the responder uses the \mStat{} method, authenticating with a
challenge-response signature.
%
The detailed message sequence chart is shown in Figure~\ref{fig:edhocsigstat}.
%
\mCredi{} and \mLtki{} must be signature keys since the initiator is using the
\mSig{} method.
%

\begin{figure}[h]
\centering
\linespread{1}
\scalebox{.7}{
\tikzset{>=latex, every msg/.style={draw=thick}, every node/.style={fill=none,text=black}}
\begin{tikzpicture}
    \node (ini) at (0, 0) {Initiator};
    \draw [very thick] (0, -0.5) -- (0,-15.5);
    \draw [very thick] (9, -0.5) -- (9,-15.5);
    \node[below=0.5em of ini,fill=white] {$
    \begin{array}{c}
    \text{Knows}\ $g$,\ \mCredi,\ \mLtki,\ \mIdcredi,\\
    \mIdcredr, \mADone,\ \mADthree
    \end{array}
    $};
    \node (res) at (9,0) {Responder};
    \node[below=0.5em of res,fill=white] {$
    \begin{array}{c}
    \text{Knows}\ $g$,\ \mCredr,\ \mLtkr, \ \mIdcredr,\\
    \mIdcredi, \mADtwo
    \end{array}$};
    \action{4.5em}{ini}{Generates \mMethod,\ \mSuites,\ \mCi,\ $x$\\$\mGx = g^{x}$};
    \msg{9em}{ini}{res}{\mMsgone: \mMethod, \mSuites, \mGx, \mCi, \mADone};
    \action{9.5em}{res}{$
      \begin{array}{c}
        \text{Generates } \mCr,\ $y$\\
        \mGy = g^{y}\\
        \mTHtwo = \mHash(\mMsgone, \langle \mCi, \mGy, \mCr \rangle)\\
        \mPRKtwo = \mHkdfExtract(\textrm{``\phantom{}''}, g^{xy}) \\
        \mGrx = \mGx^{\mLtkr} \\
        \mPRKthree = \mHkdfExtract(\mPRKtwo, \mGrx) \\
        \mKtwom = \mHkdfExpand(\mPRKthree, \mTHtwo) \\
        \mMactwo = \mAead(\mKtwom; \langle \mIdcredr, \mTHtwo, \mCredr, \mADtwo \rangle; \textrm{``\phantom{}''}) \\
        \mKtwoe = \mHkdfExpand(\mPRKtwo, \mTHtwo)
      \end{array}$};
    \msg{24em}{res}{ini}{\mMsgtwo: \mCi, \mGy, \mCr, $\overbrace{\mKtwoe\ \mXor\ \langle \mIdcredr, \mMactwo, \mADtwo \rangle}^{\mCipher}$};
    \action{25em}{ini}{$
      \begin{array}{c}
        %\mTHtwo = \mHash(\mMsgone, \langle \mCi, \mGy, \mCr \rangle) \
        \mPRKtwo = \mHkdfExtract(\textrm{``\phantom{}''}, g^{xy}) \\
        %\mKtwoe = \mHkdfExpand(\mPRKtwo,\mTHtwo)\\
        \mGrx = \mCredr^{x} \\
        \mPRKfour = \mPRKthree = \mHkdfExtract(\mPRKtwo, \mGrx) \\
        %\mKtwom = \mHkdfExpand(\mPRKthree, \mTHtwo) \\
        \mKthreeae = \mHkdfExpand(\mPRKthree, \mTHtwo) \\
        \mTHthree = \mHash(\mTHtwo, \mCipher, \mCr)\\
        \mKthreem = \mHkdfExpand(\mPRKfour, \mTHthree) \\
        \mMacthree = \mAead(\mKthreem; \langle \mIdcredi, \mTHthree, \mCredi, \mADthree \rangle; \textrm{``\phantom{}''}) \\
        \mSigthree = \mSign(\mLtki; \langle \mIdcredi, \mTHthree, \mCredi, \mADthree \rangle, \mMacthree \rangle)
      \end{array}$};
    \msg{37em}{ini}{res}{$\mMsgthree: \mCr, \mAead(\mKthreeae; \mTHthree; \langle \mIdcredi, \mSigthree, \mADthree \rangle$)};
    \action{37.5em}{res}{$
    \begin{array}{c}
        \mTHthree = \mHash(\mTHtwo, \mCipher, \mCr)\\
        \mKthreem = \mHkdfExpand(\mPRKthree, \mTHthree) \\
        \mKthreeae = \mHkdfExpand(\mPRKthree, \mTHthree)
    \end{array}$};
    \draw [line width=1mm] (-2,-15.5) -- (2,-15.5);
    \draw [line width=1mm] (7,-15.5) -- (11,-15.5);
    \end{tikzpicture}}
    \caption{The \mSigStat{} method; (\mCredi{}, \mLtki), and
        (\mCredr{}, \mLtkr{}) are public-private key pairs; $\mSign(k; x)$ is
    used to denote the signing of message $x$ using key $k$}
\label{fig:edhocsigstat}
\end{figure}
%

%------------------------------------------------------------------------- sub
\paragraph{\mStatSig}
This method mirrors the \mSigStat{} method.
%
The responder runs \mSig{} and creates \mAuthr{} as a signature over MAC,
while the initiator runs \mStat{}.
%
This is illustrated in Figure~\ref{fig:edhocstatsig}. \mCredr{} and \mLtkr{}
must be signature keys.
%

\begin{figure}[h]
\centering
\linespread{1}
\scalebox{.7}{
\tikzset{>=latex, every msg/.style={draw=thick}, every node/.style={fill=none,text=black}}
\begin{tikzpicture}
    \node (ini) at (0, 0) {Initiator};
    \draw [very thick] (0, -0.5) -- (0,-15.5);
    \draw [very thick] (9, -0.5) -- (9,-15.5);
    \node[below=0.5em of ini,fill=white,text=black] {$
    \begin{array}{c}
    \text{Knows}\ $g$,\ \mCredi,\ \mLtki,\ \mIdcredi,\\
    \mIdcredr, \mADone,\ \mADthree
    \end{array}
    $};
    \node (res) at (9,0) {Responder};
    \node[below=0.5em of res,fill=white] {$
    \begin{array}{c}
    \text{Knows}\ $g$,\ \mCredr,\ \mLtkr,\ \mIdcredr,\\
    \mIdcredi, \mADtwo
    \end{array}$};
    \action{4.5em}{ini}{Generates \mMethod,\ \mSuites,\ \mCi,\ $x$\\$\mGx = g^{x}$};
    \msg{8.5em}{ini}{res}{\mMsgone: \mMethod, \mSuites, \mGx, \mCi, \mADone};
    \action{9.5em}{res}{$
      \begin{array}{c}
        \text{Generates } \mCr,\ $y$\\
        \mGy = g^{y}\\
        \mTHtwo = \mHash(\mMsgone, \langle \mCi, \mGy, \mCr \rangle)\\
        \mPRKthree = \mPRKtwo = \mHkdfExtract(\textrm{``\phantom{}''}, g^{xy}) \\
        \mKtwom = \mHkdfExpand(\mPRKthree, \mTHtwo) \\
        \mMactwo = \mAead(\mKtwom; \langle \mIdcredr, \mTHtwo, \mCredr, \mADtwo \rangle; \textrm{``\phantom{}''}) \\
        \mSigtwo = \mSign(\mLtkr; \langle \langle \mIdcredr, \mTHtwo, \mCredr, \mADtwo \rangle, \mMactwo \rangle)\\
        \mKtwoe = \mHkdfExpand(\mPRKtwo, \mTHtwo)
      \end{array}$};
    \msg{23em}{res}{ini}{\mMsgtwo: \mCi, \mGy, \mCr, $\overbrace{\mKtwoe\ \mXor\ \langle \mIdcredr, \mSigtwo, \mADtwo \rangle}^{\mCipher}$};
    \action{24em}{ini}{$
      \begin{array}{c}
        \mPRKthree = \mPRKtwo = \mHkdfExtract(\textrm{``\phantom{}''}, g^{xy}) \\
        \mGiy = \mGy^{\mLtki} \\
        \mPRKfour = \mHkdfExtract(\mPRKthree, \mGiy) \\
        \mTHthree = \mHash(\mTHtwo, \mCipher, \mCr)\\
        \mKthreem = \mHkdfExpand(\mPRKfour, \mTHthree) \\
        \mMacthree = \mAead(\mKthreem; \langle \mIdcredi, \mTHthree, \mCredi, \mADthree \rangle; \textrm{``\phantom{}''}) \\
        \mKthreeae = \mHkdfExpand(\mPRKthree, \mTHthree) \\
      \end{array}$};
    \msg{34.7em}{ini}{res}{$\mMsgthree: \mCr, \mAead(\mKthreeae; \mTHthree; \langle \mIdcredi, \mMacthree, \mADthree \rangle$)};
    \action{35.2em}{res}{$
    \begin{array}{c}
       \mGiy = \mCredi^{y} \\
       \mPRKfour = \mHkdfExtract(\mPRKthree, \mGiy) \\
       \mTHthree = \mHash(\mTHtwo, \mCipher, \mCr)\\
        \mKthreem = \mHkdfExpand(\mPRKfour, \mTHthree) \\
        \mKthreeae = \mHkdfExpand(\mPRKthree, \mTHthree)
    \end{array}$};
    \draw [line width=1mm] (-2,-15.5) -- (2,-15.5);
    \draw [line width=1mm] (7,-15.5) -- (11,-15.5);
    \end{tikzpicture}}
\caption{The \mStatSig{} method of \mEdhoc}
\label{fig:edhocstatsig}
\end{figure}
%

\paragraph{\mStatStat}
Both the initiator and the responder use the \mStat{}
authentication method.
%
Both parties' secret static long-term DH keys feed into the key hierarchy.
%
The initiator computes authentication data using the \mAead{} transform
and includes that in the third message for the responder to verify.
%

%------------------------------------------------------------------------- sub
\subsubsection{\mSigSig}
Both parties run \mSig{} and authenticate with signatures.
%
As mentioned earlier, \mSigSig{} is very closely modeled on \mSigmaI{}, but
there are some notable differences.
%
For example, \mEdhoc{} aims to provide some degree of identity protection for
responders, and therefore uses the idea from \mSigmaI{} of encrypting the
responder identifier \mIdcredr{} (and other items) in the second message.
%
The designers of \mEdhoc{} consider it wasteful adding a second MAC in addition
to the already included \mMactwo{}, to limit bandwidth consumption.
%
\mEdhoc{} applies XOR encryption, with \mHkdf{} being used to generate the
key stream, whereas \mSigma{} assumes authenticated encryption for this
purpose (see Section 5.2 of~\cite{sigma}).
%
Because \mSigSig{} has been analyzed in~\cite{DBLP:conf/secsr/BruniJPS18}, we
do not focus on it here.
%
However, we model it and verify its properties as carefully as for the other methods.

%------------------------------------------------------------------------- sub
\subsection{Negotiating a cipher suite and method and correlation parameters}
\label{sec:ciphersuite}
Recall that we mentioned that the first message contains a list of cipher suites, ranked according to the preference of the initiator. What does a cipher suite actually contain? An \mEdhoc{} cipher suite consists of an ordered set of \mCose{} algorithms: an \mAead{} algorithm, a hash algorithm, an ECDH curve, a signature algorithm, a signature algorithm curve, an application \mAead{} algorithm, and an application hash algorithm from the \mCose{} Algorithms and Elliptic Curves registries.

There are four supported cipher suites in \mEdhoc{} -- we refer the reader to Section 3.4 of~\cite{selander-lake-edhoc-01} for the specifics of the algorithms allowed therein. Each cipher suite is identified by one of four predefined integer labels (0--3). Some algorithms are not used in some methods.  The signature algorithm and the signature algorithm curve are not used in methods without signature authentication (i.e. in \mPskPsk{} and \mStatStat).

In order to keep the presentation clean, we have omitted the cipher suite negotiation process from the description of the methods. However, this process happens as follows, at the beginning of every method, once the responder receives the first message. The initiator proposes an ordered list of cipher suites they support. This list presented in descending order to the responder who either accepts the topmost entry in this list (if they also support that suite) or makes a counter-proposal, namely the topmost entry which they support from the remaining part of the list. If there is no such entry the responder can reject, and the protocol does not continue. Similarly, the responder can reject the initiator's choices for the method and correlation parameters as well -- in the case of a reject for either of these values, the protocol aborts.

%------------------------------------------------------------------------- sub
\subsection{Claimed Security Properties}
\label{sec:claimedProperties}

We present the security properties that the authors
of the \mSpec{}~\cite{selander-lake-edhoc-01} claim \mEdhoc{} satisfies.
%
Many of the claims are imprecisely expressed.
%
We will revisit these claims when we discuss the formal modeling and
verification of \mEdhoc{} in Section~\ref{sec:formalization} and in the
discussions in Section~\ref{sec:discussion}.
%
These are our interpretations of the claimed security properties described in
the \mSpec~\cite{selander-lake-edhoc-01}, Section~8.1:
\begin{itemize}
    \item Perfect Forward Secrecy (\textbf{PFS}) for the session key material
    \item Mutual authentication (this presumably refers to entity authentication
        because it is followed by claims of
        \textbf{consistency} (defined in~\cite{sigma}),
        \textbf{aliveness}, and
        \textbf{peer awareness} to the responder, but not to the initiator)
    \item \textbf{Identity protection} (the initiator against active attacks
        and the responder against passive attacks, except for \mPskPsk{})
    \item Key Compromise Impersonation (\textbf{KCI}) resistance
    \item A single session of \mEdhoc{} enables the responder to verify
            that the selected cipher suite is the most preferred of the
            initiator which is supported by both parties, even though there is
            no negotiation of cipher suites per se.
    \item \textbf{Session key independence}
\end{itemize}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                                                                 %
%  GEANT manual in LaTeX form                                     %
%                                                                 %
%  Version 1.00                                                   %
%                                                                 %
%  Last Mod. 12 June 1993 18:20  MG                               %
%                                                                 %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\Origin{G.N.Patrick}
\Version{Geant 3.16}\Routid{PHYS400}
\Submitted {30.03.82} \Revised{16.12.93}
\Makehead{Simulation of particle decays in flight}
\section{Subroutines}
\Shubr{GDECAY}{}

\Rind{GDECAY} is the control routine for the simulation of particle
decays in flight. For a given parent particle it selects from a list a
two- or three-body decay mode using the known branching ratios and calls the
routines needed to generate the vertex and secondary tracks.
It used the following input and output:
\begin{DLtt}{MMMMMMM}
\item[input:]  via common blocks \FCind{/GCTRAK/} and \FCind{/GCKINE/}
\item[output:] via common block  \FCind{/GCKING/}
\end{DLtt}
\Rind{GDECAY} is called by the tracking routines.
It calls the subroutines
\Rind{GDECA2} for two-body decay, \Rind{GDECA3} for three-body decay,
\Rind{GLOREN} for Lorentz transformation and \Rind{GDROT} for rotation.
For the documentation of \Rind{GLOREN} and \Rind{GDROT}, see {\tt [PHYS410]}.
\Shubr{GDECA2}{(XM0,XM1,XM2,PCM)}
\begin{DLtt}{MMMMMMMM}
\item[XM0] ({\tt REAL}) mass of the parent particle
\item[XM1] ({\tt REAL}) mass of the first decay product
\item[XM2] ({\tt REAL}) mass of the second decay product
\item[PCM(3,4)] ({\tt REAL}) array containing the four-vectors of
the decay products
\end{DLtt}
{\tt GDECA2} simulates the two-body decay with isotropic angular
distribution in the center-of-mass system. It is called from
{\tt GDECAY}.
\Shubr{GDECA3}{(XM0,XM1,XM2,XM3,PCM)}
\begin{DLtt}{MMMMMMMM}
\item[XM0] ({\tt REAL}) mass of the parent particle
\item[XM1] ({\tt REAL}) mass of the first decay product
\item[XM2] ({\tt REAL}) mass of the second decay product
\item[XM3] ({\tt REAL}) mass of the third decay product
\item[PCM(3,4)] ({\tt REAL}) array containing the four-vectors of
the decay products
\end{DLtt}
{\tt GDECA3} simulates the three-body decay
with isotropic angular distribution in the center-of-mass system.
It is called from {\tt GDECAY}.

\section{Method}
\begin{itemize}
\item
Upon entry to \Rind{GDECAY} a binary search is made in a list of
parent particles. This list is stored in the {\tt JPART} structure
and currently contains the particles defined in \Rind{GPART}
{\tt [CONS300]}. If the current particle cannot be found in the list,
control is returned {\it without} any decay generation.
Up to six decay modes and their corresponding branching ratios are then
extracted from the {\tt JPART} data banks (see {\tt [CONS310]}).
\item
A decay channel is selected according to the branching ratios.
If the sum
of the branching ratios for a particle is not equal 100\%, it is
possible that {\it no} decay is selected.
\item
Depending on whether the two- or three-body decay is selected, either
\Rind{GDECA2} or \Rind{GDECA3} is called to generate the
four-momenta of the decay products with isotropic angular
distribution in the center-of-mass system.
\item
The momentum vectors of the decay products
are transformed into the laboratory
system and rotated back into the {\tt GEANT} coordinate frame.
The kinematics of the products is stored in the common \FCind{/GCKING/}.
\item
When a particle decays and no branching ratio is defined, then
\Rind{GDECAY}
calls the user routine \Rind{GUDCAY}.
\end{itemize}


\documentclass[modern]{aastex61}
\usepackage{graphicx}
\usepackage{grffile}
\usepackage{xcolor}
\usepackage[sort&compress]{natbib}
\usepackage[hang,flushmargin]{footmisc}
\usepackage{amsmath}

% units macros
\newcommand{\unit}[1]{\mathrm{#1}}
\newcommand{\km}{\unit{km}}
\newcommand{\m}{\unit{m}}
\newcommand{\s}{\unit{s}}
\newcommand{\kms}{\km\,\s^{-1}}
\newcommand{\ms}{\m\,\s^{-1}}
\newcommand{\ang}{\text{\normalfont\AA}}

% math macros
\newcommand{\dd}{\mathrm{d}}
\newcommand{\T}{^{\mathsf{T}}}

% text macros
\newcommand{\todo}[1]{\textcolor{red}{#1}}  % gotta have \usepackage{xcolor} in main doc or this won't work
\newcommand{\acronym}[1]{{\small{#1}}}
\newcommand{\project}[1]{\textsl{#1}}
\newcommand{\RV}{\acronym{RV}}
\newcommand{\CRLB}{\acronym{CRLB}}

\setlength{\parindent}{1.4em} % trust in Hogg

\shorttitle{is spectro-perfectionism perfect?}
\shortauthors{smartasses}

\begin{document}\sloppy\sloppypar\raggedbottom\frenchspacing % trust in Hogg
\graphicspath{ {figures/} }
\DeclareGraphicsExtensions{.pdf,.eps,.png}

\title{How perfect is spectro-perfectionism, really?}

\begin{abstract}\noindent
Current spectrograph performance requirements are increasing dramatically with pressure from the exoplanet community for precise radial velocity (\RV) measurements, the stellar community for detailed chemical abundances, and the cosmology community for intergalactic absorption mapping.
%Within the exoplanet community, spectrographs and their data reduction pipelines are designed with a primary goal in mind: obtaining the most precise  possible.
In some cases, design decisions are made at the instrument level to prioritize the capability of obtaining a reliably calibrated one-dimensional extracted spectrum from the two-dimensional raw data without losing much of the encoded information.
The concept of \textsl{spectro-perfectionism} outlines a way to extract spectra with minimal information loss \todo{(check that they claim this)} from any reasonable spectrograph design, at least in principle.
In this work we use \RV\ precision as a proxy for the accuracy and information content of an extracted spectrum.
We test the performances of traditional optimal extraction and of spectro-perfectionism on simulated spectra under a variety of spectrograph conditions.
We find that under [x] conditions, spectro-perfectionism is able to extract precise \RV s [at/near the Cram\'er--Rao bound], outperforming optimal extraction [by a factor of...].
However, both methods begin to fail when [x], suggesting a future need for performing spectroscopic inferences directly in the two-dimensional raw data space.
\end{abstract}

\section{Introduction}

Background on EPRV instruments and assumptions they make.

Background on optimal extraction and spectro-perfectionism

What we set out to do

\section{Data Generation}
General concept is a `photon-based' approach, meaning that a 2D spectrum is generated by repeating the following steps many times:
\begin{enumerate}
    \item select a random position in the input slit/fiber using a PDF that reflects the slit/fiber format.
    \item select a random wavelength (using the spectral source that we want to simulate as a PDF)
    \item transformation of the input position to a detector position via a (wavelength-dependent) affine transformation matrix.
The matrix represents (part of) the spectrograph optics and adjusting the matrix elements allows to define linear dispersion, the spatial format of the 2D spectrum as well as slit rotation ($\Theta$), shear and scaling (sx, sy) in dispersion and cross-dispersion direction.
    \item select a random xy distortion using a Gaussian (for now!) distribution to represent the spectrographs PSF
    \item bin the resulting detector position into detector pixels
\end{enumerate}
In equations:\\
Using

   	\[
	M_{\lambda} = \begin{pmatrix} m_{00} & m_{01} & m_{02} \\ m_{10} & m_{11} & m_{12} \\ m_{20} & m_{21} & m_{22} \end{pmatrix}  \stackrel{\text{(affine)}}{=} \begin{pmatrix} sx \cdot \cos(\Theta) & -sy \cdot \sin(\Theta+shear) & tx \\ sx \cdot \sin(\Theta) & sy \cdot \cos(\Theta+shear) & ty \\ 0 & 0 & 1 \end{pmatrix}
	\]

as an affine transformation matrix, we are calculating
\begin{equation}
    \begin{pmatrix} X \\ Y \\ 1 \end{pmatrix}_{\text{detector}} =
    \begin{pmatrix} m_{00} & m_{01} & tx \\ m_{10} & m_{11} & ty \\ 0 & 0 & 0 \end{pmatrix} \cdot
    \begin{pmatrix} X \\ Y \\ 1 \end{pmatrix}_{\text{slit}} +
    \begin{pmatrix} \Delta X \\ \Delta Y \\ 1 \end{pmatrix}_{\text{psf}}
\end{equation}
The simplest case is to have all matrix elements to be constant with wavelength except tx. That is equivalent to having pure linear dispersion and the detector rows
are perfectly aligned with the echelle orders.\\
In case a pure analytic function for the slit image is wanted, the slit input vector is replaced by $\begin{pmatrix} 0 & 0 & 1 \end{pmatrix}$.
Then, the matrix multiplication is simply a (wavelength dependent) shift but all spatial slit information come solely from the PSF.\\
The generated 2D data naturally comes with photon noise, detector readout noise can be added by adding appropriate noise on the binned detector data.
\begin{figure}
    \includegraphics[width=0.49\textwidth]{img/maroonx_data.png}
    \includegraphics[width=0.49\textwidth]{img/simulator_data.png}
    \caption{Comparison between part of a recorded MaroonX etalon spectrum (left) and simulation data with a similar spectral format and source (right).}
\end{figure}

how the data are generated, what the tunable knobs are, maybe a figure comparing fake data to e.g. MAROON-X test data or HARPS?

details on the time-series spectra we generate

\subsection{Theoretical Information Content}
since we're generating the data ourselves, it's possible to calculate the \CRLB\ on how much \RV\ information is encoded in the spectrograph images.

\section{Methods}
\subsection{Optimal Extraction}
implementation details

\subsection{Spectro-perfectionism}
implementation details, with some discussion of the trickiest parts (e.g. getting the A matrix right)

\section{Results \& Discussion}
Here's what we get when we run our two methods on data generated under a variety of conditions.

First we show that under a variety of spectrograph configurations, even ones where optimal extraction fails, spectro-perfectionism performs well.

Then we address the issues with implementing spectro-perfectionism in the real world: insert reasonable levels of noise into the algorithm and see where/how it breaks.

\section{Conclusions}

summarize results: conditions under which spectro-perfectionism is a good option, conditions under which optimal extraction will do, and conditions under which they both break

emphasize that even if both algorithms break, the \RV\ content is still in the 2D spectrograph images! future outlook on 2D modeling to get \RV s WITHOUT extracting a spectrum.

\bibliographystyle{apj}
\bibliography{}%general,myref,inprep}

\end{document}