status-im/research
2
0
Fork 0
mirror of https://github.com/status-im/research.git synced 2025-01-27 07:15:14 +00:00
Code Issues Projects Releases Wiki Activity

added casper econ paper

Browse Source
This commit is contained in:
Virgil Griffith 2017-08-07 17:23:24 +08:00 committed by GitHub
parent 45e5c825b1
commit 99ac31e4fa
7 changed files with 1259 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
casper4/papers/casper-economics/appendix.tex Normal file
View File

@ -0,0 +1,10 @@
\clearpage
\part*{Appendix}
\section{Unused text}
\todo{This is where text goes that for which a home hasn't been found yet. If no home is found, it will be deleted.}
Two other reasons to participate in stake pools are (i) to mitigate \emph{key theft risk} (i.e. an attacker hacking into their online machine and stealing the key), and (ii) to mitigate \emph{liveness risk}, the possibility that the validator node will go offline, perhaps because the operator does not have the time to manage a high-uptime setup.

BIN
casper4/papers/casper-economics/casper_economics_basic.pdf Normal file
View File

Binary file not shown.

331
casper4/papers/casper-economics/casper_economics_basic.tex Normal file
View File

@ -0,0 +1,331 @@
\title{Incentives in Casper the Friendly Finality Gadget}
\author{
Vitalik Buterin \\
Ethereum Foundation
}
\documentclass[12pt, final]{article}
\input{eth_header.tex}
%% Special symbols we'll probably iterate on
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%\newcommand{\epoch}{ \mathscr{E} }
%\newcommand{\hash}{\ensuremath{ \mathscr{H} }}
%\newcommand{\epoch}{ {\footnotesize \textnormal{\textestimated} } }
\newcommand{\epoch}{\ensuremath{e}}
\newcommand{\hash}{\textnormal{h}}
%\newcommand{\epoch}{ \ensuremath{ \mathcal{E} } }
%\newcommand{\hash}{\ensuremath{ \mathcal{H} }}
%\newcommand{\epoch}{ \ensuremath{ \mathds{E} } }
%\newcommand{\hash}{\ensuremath{ \mathds{H} }}
\newcommand{\hashsource}{\hash_{\star}\xspace}
\newcommand{\epochsource}{\epoch_{\star}\xspace}
\newcommand{\BIR}{\textsc{BIR}\xspace}
\newcommand{\BP}{\textsc{BP}\xspace}
\newcommand{\NCP}{\textsc{NCP}\xspace}
\newcommand{\NCCP}{\textsc{NCCP}\xspace}
\newcommand{\NPP}{\textsc{NPP}\xspace}
\newcommand{\NPCP}{\textsc{NPCP}\xspace}
\newcommand{\totaldeposit}{ \textbf{TD} \xspace}
\newcommand{\gamesymbol}{ \rotatebox[origin=c]{180}{G} }
\newcommand{\msgPREPARE}{\textbf{\textsc{PREPARE}}\xspace}
\newcommand{\msgCOMMIT}{\textbf{\textsc{COMMIT}}\xspace}
\newcommand{\LFE}{ \ensuremath{\epoch_{\leftarrow}} \xspace}
\newcommand{\LFH}{ \ensuremath{\hash_{\leftarrow}} \xspace} % we may not need this one
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{document}
\maketitle
\begin{center} \vspace{-15pt} {\red{\today}} \end{center}
\begin{abstract}
We give an introduction to the incentives in the Casper the Friendly Finality Gadget protocol, and show how the protocol behaves under individual choice analysis, collective choice analysis and griefing factor analysis. We define a ``protocol utility function'' that represents the protocol's view of how well it is being executed, and show the connection between the incentive structure that we present and the utility function. We show that (i) the protocol is a Nash equilibrium assuming any individual validator's deposit makes up less than $\frac{1}{3}$ of the total, (ii) in a collective choice model, where all validators are controlled by one actor, harming protocol utility hurts the cartel's revenue, and there is an upper bound on the ratio between the reduction in protocol utility from an attack and the cost to the attacker, and (iii) the griefing factor can be bounded above by $1$, though we will prefer an alternative model that bounds the griefing factor at $2$ in exchange for other benefits.
\end{abstract}
\section{Introduction}
In the Casper protocol, there is a set of validators, and in each epoch validators have the ability to send two kinds of messages:
\begin{table}[h!bt]
\centering
\subfloat[\msgPREPARE]{ \begin{tabular}{|c|} \toprule
epoch \\
\midrule
hash \\
\midrule
$hash_{source}$ \\
\midrule
$epoch_{source}$ \\
\bottomrule
\end{tabular} \label{tbl:prepare} } \hspace{1in}
\subfloat[\msgCOMMIT]{ \begin{tabular}{|c|} \toprule
~~~epoch~~~ \\
\midrule
~~~hash~~~ \\
\bottomrule
\end{tabular} \label{tbl:commit} }
\caption{The schematic of the \msgPREPARE and \msgCOMMIT messages.}
\label{fig:messages}
\end{table}
Each validator has a \emph{deposit size}; when a validator joins their deposit size is equal to the number of coins that they deposited, and from there on each validator's deposit size rises and falls as the validator receives rewards and penalties. For the rest of this paper, when we say ``$\frac{2}{3}$ of validators'', we are referring to a \emph{deposit-weighted} fraction; that is, a set of validators whose combined deposit size equals to at least $\frac{2}{3}$ of the total deposit size of the entire set of validators. We also use ``$\frac{2}{3}$ commits'' as shorthand for ``commits from $\frac{2}{3}$ of validators''.
If, during an epoch $\epoch$, for some specific checkpoint hash $\hash$, $\frac{2}{3}$ prepares are sent of the form
\begin{equation}
[PREPARE, \epoch, \hash, \epochsource, \hashsource]
\end{equation}
with some specific $\epochsource$ and some specific $\hashsource$, then $\hash$ is considered \emph{justified}. If $\frac{2}{3}$ sends a Commit of the form
\begin{equation}
[COMMIT, \epoch, \hash]
\end{equation}
then $\hash$ is considered \emph{finalized}. The $\hash$ is the block hash of the block at the start of the epoch, so a $\hash$ being finalized means that block, and all of its ancestors, are finalized. An ``ideal execution'' of the protocol is one where, at the start of every epoch, every validator Prepares and Commits some block hash, specifying the same $\epochsource$ and $\hashsource$. We want to try to create incentives to encourage this ideal execution.
Possible deviations from this ideal execution that we want to minimize or avoid include:
\begin{itemize}
\item Any of the four slashing conditions \cite{minslashing} get violated.
\item During some epoch, we do not get $\frac{2}{3}$ Prepares for the same $(h, \hashsource, \epochsource)$ combination.
\item During some epoch, we do not get $\frac{2}{3}$ Commits for the $hash$ that received $\frac{2}{3}$ prepares. \todo{there can be multiple hashes that received 2/3 prepares, right?}
\end{itemize}
From within the view of the blockchain, we only see the blockchain's own history, including messages that were passed in. In a history that contains some blockhash $H$, our strategy is to reward validators who prepared and committed $H$, and not reward prepares or commits for any hash $H^\prime \ne H$.
The blockchain state will also keep track of the most recent hash in its own history that received $\frac{2}{3}$ prepares, and only reward prepares whose $\epochsource$ and $\hashsource$ point to this hash. These two techniques will help to ``coordinate'' validators toward preparing and committing a single hash with a single source, as required by the protocol.
\section{Rewards and Penalties}
We define the following constants and functions:
\begin{itemize}
\item $\BIR(\totaldeposit)$: determines the base interest rate paid to a validator, taking as an input the current total quantity of deposited ether.
\item $\BP(\totaldeposit, e, \LFE )$: determines the ``base penalty constant'' - a value expressed as a percentage rate that is used as the ``scaling factor'' for all penalties; for example, if at the current time $\BP(\cdot, \cdot, \cdot) = 0.001$, then a penalty of size $1.5$ means a validator loses $0.15\%$ of their deposit. Takes as inputs the current total quantity of deposited ether $\totaldeposit$, the current epoch $e$ and the last finalized epoch \LFE. Note that in a ``perfect'' protocol execution, $\epoch - \LFE$ always equals $1$.
\item $\NCP$ (``non-commit penalty''): the penalty for not committing, if there was a justified hash which the validator \emph{could} have committed. \NCP is a constant and $\NCP > 0$.
\item $\NCCP(\alpha)$ (``non-commit collective penalty''): if $\alpha$ of validators are not seen to have committed during an epoch, and that epoch had a justified hash so any validator \emph{could} have committed, then all validators are charged a penalty proportional to $\NCCP(\alpha)$. Must be monotonically increasing, and satisfy $NCCP(0) = 0$.
\item $\NPP$ (``non-prepare penalty''): the penalty for not preparing. \NPP is a constant and $\NPP > 0$.
\item $\NPCP(\alpha)$ (``non-prepare collective penalty''): if $\alpha$ of validators ($0 \leq \alpha \leq 1$) are not seen to have prepared during an epoch, then all validators are charged a penalty proportional to $NCCP(\alpha)$. Must be monotonically increasing, and satisfy $\NPCP(0) = 0$.
\end{itemize}
Aside from $\BP$ (which has no units), all expressions have units of \emph{coins}.
Note that preparing and committing does not guarantee that the validator will not incur \NPP and \NCP; it could be the case that either because of very high network latency or a malicious majority censorship attack, the prepares and commits are not included into the blockchain in time and so the incentivization mechanism does not know about them. For $\NPCP$ and $NCCP$ similarly, the $\alpha$ input is the proportion of validators whose prepares and commits are \emph{included}, not the portion of validators who \emph{tried to send} prepares and commits.
When we talk about preparing and committing the ``correct value'', we are referring to the $hash$ and $\epochsource$ and $\hashsource$ recommended by the protocol state, as described above.
We now define the following reward and penalty schedule, which runs every epoch.
\begin{itemize}
\item Let $\totaldeposit$ be the current \emph{total amount of deposited ether}, and $\epoch - \LFE$ be the number of epochs since the last finalized epoch.
\item All validators get a reward of $\BIR(\totaldeposit)$ every epoch (eg. if $\BIR(\totaldeposit) = 0.0002$ then a validator with $10,000$ coins deposited gets a per-epoch reward of $2$ coins)
\item If the protocol does not see a Prepare from a given validator during the given epoch, they are penalized $\BP(\totaldeposit, \epoch, \LFE) * \NPP$
\item If the protocol saw Prepares from proportion $p_P$ validators during the given epoch, \emph{every} validator is penalized $\BP(\totaldeposit, \epoch, \LFE) * \NPCP(1 - p_P)$
\item If the protocol does not see a Commit from a given validator during the given epoch, and a Prepare was justified so a Commit \emph{could have} been seen, they are penalized $\BP(\totaldeposit, E, \LFE) * \NCP$.
\item If the protocol saw Commits from proportion $p_C$ validators during the previous epoch, and a Prepare was justified so a validator \emph{could have} committed, then \emph{every} validator is penalized $\BP(\totaldeposit, \epoch, \LFE) * \NCCP(1 - p_P)$
\end{itemize}
This is the entirety of the incentivization structure, though without functions and constants defined; we will define these later, attempting as much as possible to derive the specific values from desired objectives and first principles. For now we will only say that all functions output non-negative values for any input within their range.
\section{Claims}
We seek to prove the following:
\begin{enumerate}
\item If each validator has less than $\frac{1}{3}$ of total deposits, i.e., $\max_i(D) \leq \frac{\totaldeposit}{3}$, then preparing and committing the value suggested by the proposal mechanism is a Nash equilibrium.
\item Even if all validators collude, the ratio between the harm incurred by the protocol and the penalties paid by validators is bounded above by some constant. Note that this requires a measure of ``harm incurred by the protocol''; we will discuss this in more detail later.
\item The \emph{griefing factor}, the ratio between penalties incurred by validators who are victims of an attack and penalties incurred by the validators that carried out the attack, even when the attacker holds a majority of the total deposit, the griefing factor is upperbounded by 2.
\end{enumerate}
\section{Individual choice analysis}
The individual choice analysis is simple. Suppose that the proposal mechanism selects a hash $\hash$ to Prepare for epoch $e$, and the Casper incentivization mechanism specifies some $\epochsource$ and $\hashsource$. Because, as per definition of the Nash equilibrium, we are assuming that all validators except for one particular validator that we are analyzing is following the equilibrium strategy, we know that $\ge \frac{2}{3}$ of validators prepared in the last epoch and so $\epochsource = \epoch - 1$, and $\hashsource$ is the direct parent of $\hash$.
Hence, the PREPARE\_COMMIT\_CONSISTENCY slashing condition poses no barrier to preparing $(e, H, \epochsource, \hashsource)$. Since, in epoch $e$, we are assuming that all other validators \emph{will} Prepare these values and then Commit $H$, we know $H$ will be a hash in the main chain, and so a validator will pay a penalty proportional to $\NPP$ (plus a further penalty from their marginal contribution to the $\NPCP$ penalty) if they do not Prepare $(e, H, \epochsource, \hashsource)$, and they can avoid this penalty if they do Prepare these values.
We are assuming that there are $\frac{2}{3}$ prepares for $(e, H, \epochsource, \hashsource)$, and so PREPARE\_REQ poses no barrier to committing $H$. Committing $H$ allows a validator to avoid \NCP (as well as their marginal contribution to $\NCCP$). Hence, there is an economic incentive to Commit $H$. This shows that, if the proposal mechanism succeeds at presenting to validators a single primary choice, preparing and committing the value selected by the proposal mechanism is a Nash equilibrium.
\section{Collective choice model}
To model the protocol in a collective-choice context, we will first define a \emph{protocol utility function}. The protocol utility function defines ``how well the protocol execution is doing''. Although the protocol utility function cannot be derived mathematically, it can only be conceived and justified intuitively.
Our protocol utility function is,
\begin{equation}
U = \sum_{k = 0}^{\epoch} - \log_2\left[ k - \LFE \right] - M * F \; .
\end{equation}
Where:
\begin{itemize}
\item $\epoch$ is the current epoch, starting from $0$.
\item $\LFE$ is the index of the last finalized epoch before $\epoch$.
\item $M$ is a very large constant.
\item $F$ is an Indicator function. It returns $1$ if a safety failure has taken place, otherwise 0.
\end{itemize}
The second term in the function is easy to justify: safety failures are very bad. The first term is trickier. To see how the first term works, consider the case where every epoch such that $\epoch$ mod $N$, for some $N$, is zero is finalized and other epochs are not. The average total over each $N$-epoch slice will be roughly $\sum_{i=1}^N -\log_2(i) \approx N * \left[ \log_2(N) - \frac{1}{\ln(2)} \right]$. Hence, the utility per block will be roughly $-\log_2(N)$. This basically states that a blockchain with some finality time $N$ has utility roughly $-\log(N)$, or in other words \emph{increasing the finality time of a blockchain by a constant factor causes a constant loss of utility}. The utility difference between 1 minute finality and 2 minute finality is the same as the utility difference between 1 hour finality and 2 hour finality.
This can be justified in two ways. First, one can intuitively argue that a user's psychological estimation of the discomfort of waiting for finality roughly matches a logarithmic schedule. At the very least, the difference between 3600sec and 3610sec finality feels much more negligible than the difference between 1sec finality and 11sec finality, and so the claim that the difference between 10sec finality and 20sec finality is similar to the difference between 1 hour finality and 2 hour finality should not seem farfetched. \footnote{One can look at various blockchain use cases, and see that they are roughly logarithmically uniformly distributed along the range of finality times between around 200 miliseconds (``Starcraft on the blockchain'') and one week (land registries and the like). \todo{add a citation for this or delete.}}
Now, we need to show that, for any given total deposit size, $\frac{loss\_to\_protocol\_utility}{validator\_penalties}$ is bounded. There are two ways to reduce protocol utility: (i) cause a safety failure, and (ii) have $\ge \frac{1}{3}$ of validators not Prepare or not Commit to prevent finality. In the first case, validators lose a large amount of deposits for violating the slashing conditions. In the second case, in a chain that has not been finalized for $\epoch - \LFE$ epochs, the penalty to attackers is at least,
\begin{equation}
\min \left[ \NPP * \frac{1}{3} + \NPCP\left(\frac{1}{3}\right), \NCP * \frac{1}{3} + \NCCP\left(\frac{1}{3}\right) \right] * \BP(\totaldeposit, \epoch, \LFE) \; .
\end{equation}
To enforce a ratio between validator losses and loss to protocol utility, we set,
\begin{equation}
\BP(\totaldeposit, \epoch, \LFE) \equiv \frac{k_1}{\totaldeposit^p} + k_2 * \lfloor \log_2(\epoch - \LFE) \rfloor\; .
\end{equation}
\TODO{what is $p$ in the in the above equation?}
The first term serves to take profits for non-committers away; the second term creates a penalty which is proportional to the loss in protocol utility.
This connection between validator losses and loss to protocol utility has several consequences. First, it establishes that harming the protocolexecution is costly, and harming the protocol execution more costs more. Second, it establishes that the protocol approximates the properties of a \emph\emph{potential game} [cite]. Potential games have the property that Nash equilibria of the game correspond to local maxima of the potential function (in this case, protocol utility), and so correctly following the protocol is a Nash equilibrium even in cases where a coalition has more than $\frac{1}{3}$ of the total validators. Here, the protocol utility function is not a perfect potential function, as it does not always take into account changes in the \emph{quantity} of prepares and commits whereas validator rewards do, but it does come close.
\section{Griefing factor analysis}
Griefing factor analysis is important because it provides a way to quanitfy the risk to honest validators. In general, if all validators are honest, and if network latency stays below half \todo{half, right?} the length of an epoch, then validators face zero penalties to their respective deposits. In the case where malicious validators exist, however, they can interfere in the protocol in ways that penalize themselves as well as honest validators.
We define the ``griefing factor'' as,
\begin{equation}
\mathscr{GF}(\gamesymbol,C) \equiv \max_{S \in strategies(T \setminus C)} \frac{loss(C) }{\min[ 0, loss(Players \setminus C) ] } \; .
\end{equation}
\TODO{I need to work on this equation more. I don't like it yet.}
\begin{definition}
A strategy used by a coalition in a given mechanism has a \emph{griefing factor} $B$ if it can be shown that this strategy imposes a loss of $B * x$ to those outside the coalition at the cost of a loss of $x$ to those inside the coalition. If all strategies that cause deviations from some given baseline state have griefing factors less than or equal to some bound B, then we call B a \emph{griefing factor bound}. \todo{I plan to write this in terms of classical game theory.}
\end{definition}
A strategy that imposes a loss to outsiders either at no cost to a coalition, or to the benefit of a coalition, is said to have a griefing factor of infinity. Proof of work blockchains have a griefing factor bound of infinity because a 51\% coalition can double its revenue by refusing to include blocks from other participants and waiting for difficulty adjustment to reduce the difficulty. With selfish mining, the griefing factor may be infinity for coalitions of size as low as 23.21\%. \todo{citation?}
\begin{figure}[h!bt]
\centering
\includegraphics[width=3in]{cs.pdf}
\caption{Plotting the griefing factor as a function of the proportion of players coordinating to grief.}
\label{fig:GF}
\end{figure}
Let us start off our griefing analysis by not taking into account validator churn, so the validator set is always the same. In Casper, we can identify the following deviating strategies:
\begin{enumerate}
\item A minority of validators do not prepare, or Prepare incorrect values.
\item (Mirror image of 1) A censorship attack where a majority of validators does not accept prepares from a minority of validators (or other isomorphic attacks such as waiting for the minority to Prepare hash $H_1$ and then preparing $H_2$, making $H_2$ the dominant chain and denying the victims their rewards).
\item A minority of validators do not commit.
\item (Mirror image of 3) A censorship attack where a majority of validators does not accept commits from a minority of validators.
\end{enumerate}
Notice that, from the point of view of griefing factor analysis, it is immaterial whether or not any hash in a given epoch was justified or finalized. The Casper mechanism only pays attention to finalization in order to calculate $\BP(D, e, \LFE)$, the penalty scaling factor. This value scales penalties evenly for all participants, so it does not affect griefing factors.
Let us now analyze the attack types:
\begin{table}
\renewcommand{\arraystretch}{2}
\begin{tabular}{l l l }
\toprule
\textbf{Attack} & \textbf{Amount lost by attacker} & \textbf{Amount lost by victims} \\
\midrule
Minority of size $\alpha < \frac{1}{2}$ non-prepares & $\NPP * \alpha + \NPCP(\alpha) * \alpha$ & $\NPCP(\alpha) * (1-\alpha)$ \\
Majority censors $\alpha < \frac{1}{2}$ prepares & $\NPCP(\alpha) * (1-\alpha)$ & $\NPP * \alpha + \NPCP(\alpha) * \alpha$ \\
Minority of size $\alpha < \frac{1}{2}$ non-commits & $\NCP * \alpha + \NCCP(\alpha) * \alpha$ & $\NCCP(\alpha) * (1-\alpha)$ \\
Majority censors $\alpha < \frac{1}{2}$ commits & $\NCCP(\alpha) * (1-\alpha)$ & $\NCP * \alpha + \NCCP(\alpha) * \alpha$ \\
\bottomrule
\end{tabular}
\end{table}
In general, we see a perfect symmetry between the non-Commit case and the non-Prepare case, so we can assume $\frac{\NCCP(\alpha)}{\NCP} = \frac{\NPCP(\alpha)}{\NPP}$. Also, from a protocol utility standpoint, we can make the observation that seeing $\frac{1}{3} \le p_c < \frac{2}{3}$ commits is better than seeing fewer commits, as it gives at least some economic security against finality reversions, so we want to reward this scenario more than the scenario where we get $\frac{1}{3} \le p_c < \frac{2}{3}$ prepares. Another way to view the situation is to observe that $\frac{1}{3}$ non-prepares causes \emph{everyone} to non-commit, so it should be treated with equal severity.
In the normal case, anything less than $\frac{1}{3}$ commits provides no economic security, so we can treat $p_c < \frac{1}{3}$ commits as equivalent to no commits; this thus suggests $\NPP = 2 * \NCP$. We can also normalize $\NCP = 1$.
Now, let us analyze the griefing factors, to try to determine an optimal shape for $\NCCP$. The griefing factor for non-committing is,
\begin{equation}
\mathscr{GF} = \frac{(1-\alpha) * \NCCP(\alpha)}{\alpha * (1 + \NCCP(\alpha))} \; .
\end{equation}
The griefing factor for censoring is the inverse of this. If we want the griefing factor for non-committing to equal one, then we could compute:
\begin{eqnarray}
\alpha * (1 + \NCCP(\alpha)) &=& (1-\alpha) * \NCCP(\alpha) \\
\frac{1 + \NCCP(\alpha)}{\NCCP(\alpha)} &=& \frac{1-\alpha}{\alpha} \\
\frac{1}{\NCCP(\alpha)} &=& \frac{1-\alpha}{\alpha} - 1 \\
\NCCP(\alpha) &=& \frac{\alpha}{1-2\alpha}
\end{eqnarray}
Note that for $\alpha = \frac{1}{2}$, this would set the \NCCP to infinity. Hence, with this design a griefing factor of $1$ is infeasible. We \emph{can} achieve that effect in a different way - by making \NCP itself a function of $\alpha$; in this case, $\NCCP = 1$ and $\NCP = \max[0, 1 - 2 * \alpha]$ would achieve the desired effect. If we want to keep the formula for \NCP constant, and the formula for \NCCP reasonably simple and bounded, then one alternative is to set $\NCCP(\alpha) = \frac{\alpha}{1-\alpha}$; this keeps griefing factors bounded between $\frac{1}{2}$ and $2$.
\section{Pools}
In a traditional (ie. not sharded or otherwise scalable) blockchain, there is a limit to the number of validators that can be supported, because each validator imposes a substantial amount of overhead on the system. If we accept a maximum overhead of two consensus messages per second, and an epoch time of 1400 seconds, then this means that the system can handle 1400 validators (not 2800 because we need to count prepares and commits). Given that the number of individual users interested in staking will likely exceed 1400, this necessarily means that most users will participate through some kind of ``stake pool''.
There are several possible kinds of stake pools:
\begin{itemize}
\item \textbf{Fully centrally managed}: users $B_1 \ldots B_n$ send coins to pool operator $A$. $A$ makes a few deposit transactions containing their combined balances, fully controls the Prepare and Commit process, and occasionally withdraws one of their deposits to accommodate users wishing to withdraw their balances. Requires complete trust.
\item \textbf{Centrally managed but trust-reduced}: users $B_1 \ldots B_n$ send coins to a pool contract. The contract sends a few deposit transactions containing their combined balances, assigning pool operator $A$ control over the Prepare and Commit process, and the task of keeping track of withdrawal requests. $A$ occasionally withdraws one of their deposits to accommodate users wishing to withdraw their balances; the withdrawals go directly into the contract, which ensures each user's right to withdraw a proportional share. Users need to trust the operator not to get their deposits penalized, but the operator cannot steal the coins. The trust requirement can be reduced further if the pool operator themselves contributes a large portion of the coins, as this will disincentivize them from staking maliciously.
\item \textbf{2-of-3}: a user makes a deposit transaction and specifies as validation code a 2-of-3 multisig, consisting of (i) the user's online key, (ii) the pool operator's online key, and (iii) the user's offline backup key. The need for two keys to sign off on a prepare, Commit or withdraw minimizes key theft risk, and a liveness failure on the pool side can be handled by the user using their backup key.
\item \textbf{Multisig managed}: users $B_1 \ldots B_n$ send coins to a pool contract that works in the exact same way as a centrally managed pool, except that a multisig of several semi-trusted parties needs to approve each Prepare and Commit message.
\item \textbf{Collective}: users $B_1 \ldots B_n$ send coins to a pool contract that that works in the exact same way as a centrally managed poolg
, except that a threshold signature of at least portion $p$ of the users themselves (say, $p = 0.6$) needs to approve each Prepare and Commit messagge.
\end{itemize}
We expect pools of different types to emerge to accomodate smaller users. In the long term, techniques such as blockchain sharding will make it possible to increase the number of users that can validate directly, and extensions to allow validators to temporarily ``drop out'' from the validator set when they are offline can mitigate liveness risk.
\section{Conclusions}
The above analysis gives a parametrized scheme for incentivizing in Casper, and shows that it is a Nash equilibrium in an uncoordinated-choice model with a wide variety of settings. We then attempt to derive one possible set of specific values for the various parameters by starting from desired objectives, and choosing values that best meet the desired objectives. This analysis does not include non-economic attacks, as those are covered by other materials, and does not cover more advanced economic attacks, including extortion and discouragement attacks. We hope to see more research in these areas, as well as in the abstract theory of what considerations should be taken into account when designing reward and penalty schedules.
\textbf{Future Work.} \todo{fill me in}
\textbf{Acknowledgements.} We thank Virgil Griffith for review.
\section{References}
\bibliographystyle{abbrv}
\bibliography{ethereum}
Optimal selfish mining strategies in Bitcoin; Ayelet Sapirshtein, Yonatan Sompolinsky, and Aviv Zohar: https://arxiv.org/pdf/1507.06183.pdf
Potential games; Dov Monderer and Lloyd Shapley: \url{http://econpapers.repec.org/article/eeegamebe/v\_3a14\_3ay\_3a1996\_3ai\_3a1\_3ap\_3a124-143.htm}
\input{appendix.tex}
\end{document}

109
casper4/papers/casper-economics/eth_header.tex Normal file
View File

@ -0,0 +1,109 @@
% make in NIPS format
\usepackage{nips10submit_e}
\nipsfinalcopy
\usepackage{graphicx}
\DeclareGraphicsExtensions{.pdf,.eps,.png,.jpg} % search for .pdf, then .eps, then .pngs, then .jpg
% look in these subdirectories for graphics referenced by \includegraphics
% each entry must end with a /
\graphicspath{{figs/}{figures/}{images/}{./}}
\newcommand*{\red}[1]{ \color{red} #1}
\usepackage{tabularx}
\usepackage{url}
\usepackage{cite}
\usepackage{amsmath}
\usepackage{ lmodern } % I prefer this over times
\usepackage{array} % replacement for eqnarray. Must be BEFORE \usepackage{arydshln}
\usepackage{units} % for \nicefrac{\alpha}{\beta}
\usepackage{amsthm} % for theorems
\newtheorem{definition}{Definition}
\usepackage{microtype}
%\usepackage{wasysym}
\usepackage{textcomp, marvosym} % pretty symbols
\usepackage{booktabs} % for much better looking tables
% for indicator functions
\usepackage{dsfont}
% for pretty Euler script
\usepackage[mathscr]{euscript}
\usepackage{fullpage} % save trees
\usepackage{subfig}
%\usepackage{float} % for \subfloat
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% More customizable Lists
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Better symbols custom enumerative lists, define any symbol you'd like
\usepackage{enumitem}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% Custom Symbols
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% \xspace at the end of custom macros never fucks up spacing.
% example of best practice: \newcommand{\apples}{\textsf{AppLeS}\xspace}
\usepackage{xspace}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% Abbreviations you'll always want
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\newcommand*{\TODO}[1]{{\centering {\sffamily \color{red} #1} \vskip10pt }}
\newcommand*{\todo}[1]{{\sffamily [{\color{red} #1}]}}
\newcommand*{\fix}[1]{{\sffamily [{\textnormal{\color{red} #1}}]}}
%-----------------------------------------------------------------------------
% Cross references
%-----------------------------------------------------------------------------
% The following code defines how you make references to figures, tables, etc...
% It is defined in one place only, and can be modified for all references
% in the document at the same time.
% Instead of typing each time: "see Fig. \ref{myfig}" you can create a command
% \figref which will do the job. Then in text you only type \figref{myfig} and LaTeX
% will do the rest.
\newcommand{\tblref}[1]{Table~\ref{#1}}
%\renewcommand*{\figref}[1]{Fig.~\ref{#1}}
\newcommand{\equref}[1]{(\ref{#1})}
\newcommand{\Tblref}[1]{Table~\ref{#1}}
\newcommand{\Figref}[1]{Figure~\ref{#1}}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%-----------------------------------------------------------------------------
% Misc symbols that I like
%-----------------------------------------------------------------------------
\newcommand*{\opname}[1]{\operatorname{#1}}
\renewcommand*{\to}{\rightarrow}
%%%%

573
casper4/papers/casper-economics/ethereum.bib Normal file
View File

@ -0,0 +1,573 @@
%% This BibTeX bibliography file was created using BibDesk.
%% http://bibdesk.sourceforge.net/
%% Created for Virgil Griffith at 2017-04-21 14:15:31 +0800
%% Saved with string encoding Unicode (UTF-8)
@misc{minslashing,
title={Minimal Slashing Conditions},
author={Vitalik Buterin},
year={2017},
month={03},
day={02},
url={https://medium.com/@VitalikButerin/minimal-slashing-conditions-20f0b500fc6c}
}
@misc{truebit,
title={A scalable verification solution for blockchains},
author={Jason Teustch and Christian Reitwießner},
year={2017},
month={03},
day={07},
url={https://truebit.io/}
}
@article{ostrom2002,
title={Type of good and collective action},
author={Ostrom, Elinor},
journal={unpublished paper},
pages={15},
year={2002}
}
@misc{barder14,
title={A Global Carbon Tax or Cap-and-Trade? Part 1: The Economic Arguments},
author={Alice Lépissier and Owen Barder},
year={2014},
month={09},
day={08},
url={https://www.cgdev.org/blog/global-carbon-tax-or-cap-and-trade-part-1-economic-arguments}
}
@misc{braveICO,
author={Jon Southurst},
title={BAT Token Sale Causes Hours of Ethereum Network Delays},
year={2017},
month={05},
day={31},
url={http://www.bitsonline.com/bat-sale-ethereum-network-delays/}
}
@techreport{ibm2011,
title = {GPFS Scans 10 Billion Files in 43 Minutes},
author = {Richard F. Freitas, Joe Slember, Wayne Sawdon, and Lawrence Chiu},
year = {2011},
institution = {IBM},
month = {07},
day={22},
url={https://domino.research.ibm.com/library/CyberDig.nsf/papers/4A50C2D66A1F90F7852578E3005A2034/$File/rj10484.pdf}
}
@misc{infura,
author={Consensys},
title={INFURA},
year={2017},
month={06},
day={01},
url={https://infura.io}
}
@misc{spectrumetcalfe,
author={Bob Briscoe, Andrew Odlyzko, and Benjamin Tilly},
title={Metcalfe's Law is Wrong},
year={2006},
month={06},
day={01},
url={http://spectrum.ieee.org/computing/networks/metcalfes-law-is-wrong}
}
@misc{env-econ,
author={Tim Haab},
title={The long run elasticity of demand for gas},
year={2008},
month={06},
day={23},
url={http://www.env-econ.net/2008/06/the-long-run-el.html}
}
@inproceedings{cornell-position,
title={On Scaling Decentralized Blockchains},
author={Kyle Croman, Christian Decker, Ittay Eyal, Adem Efe Gencer, Ari Juels},
Year={2017},
Booktitle={3rd Workshop on Bitcoin and Blockchain Research},
Organization={International Financial Cryptography Association}
url={http://fc16.ifca.ai/bitcoin/papers/CDE+16.pdf}
}
@misc{medium-codetract,
author={CodeTract},
title={BAT ICO, USD 35 million in 24 seconds, gas and gasPrice},
year={2017},
month={06},
day={01},
url={https://medium.com/@codetractio/bat-ico-usd-35-million-in-24-seconds-gas-and-gasprice-6cdde370a615}
}
@misc{vitalik-uncle-rate,
author={Vitalik Buterin},
title={Uncle Rate and Transaction Fee Analysis},
year={2016},
month={10},
day={31},
url={https://blog.ethereum.org/2016/10/31/uncle-rate-transaction-fee-analysis/}
}
@misc{vitalik-twitter1,
author={Vitalik Buterin},
title={Tweet},
year={2017},
month={06},
day={03},
url={https://twitter.com/VitalikButerin/status/871218258212290560}
}
@misc{reddit-rec-miners,
author={Hudson Jameson},
title={Recommendations to miners to change gas limit and gas price settings},
year={2017},
month={05},
day={31},
url={https://www.reddit.com/r/ethereum/comments/6ehp60/recommendations_to_miners_to_change_gas_limit_and/}
}
@misc{coindesk-btc-txn-fee,
author={Danny Bradbury},
title={Bitcoin Transaction Fees To Be Slashed Tenfold},
year={2014},
month={02},
day={28},
url={http://www.coindesk.com/bitcoin-transaction-fees-slashed-tenfold/}
}
@misc{vitalik-coord,
author={Vitalik Buterin},
title={Engineering Security Through Coordination Problems},
year={2017},
month={05},
day={08},
url={http://vitalik.ca/general/2017/05/08/coordination_problems.html}
}
@misc{etherchaingas,
author={Etherchain},
title={Economic gas price estimation},
year={2017},
month={05},
day={1},
url={https://etherchain.org/statistics/gasPrice}
}
@misc{40years,
author = {Karl Rupp},
title = {40 Years of Microprocessor Trend Data},
year = {2015},
month={06},
day={25},
url = {https://www.karlrupp.net/2015/06/40-years-of-microprocessor-trend-data/},
}
@misc{wiki:runaway,
author = {Wikipedia},
title = {Runaway climate change --- Wikipedia{,} The Free Encyclopedia},
year = {2017},
url = {https://en.wikipedia.org/w/index.php?title=Runaway_climate_change&oldid=776345569},
note = {[Online; accessed 5-May-2017]}
}
@misc{wood2014ethereum,
title={Ethereum: A Secure Decentralized Generalized Transaction Ledger},
author={Gavin Wood},
year={2014},
url={http://yellowpaper.io/}
}
@article{weitzman1974prices,
title={Prices vs. quantities},
author={Martin L Weitzman},
journal={The review of economic studies},
volume={41},
number={4},
pages={477--491},
year={1974},
publisher={JSTOR}
}
@misc{bip:141,
Author = {Eric Lombrozo, Johnson Lau, and Pieter Wuille},
Title = {BIP 141: Segregated Witness},
Url = {https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki},
Year = {2015},
Month = {12},
Day = {21}
}
@book{knight1921risk,
title={Risk, uncertainty and profit},
author={Knight, Frank H},
year={1921},
publisher={Courier Corporation}
}
@inproceedings{fc17ai,
Title={A Smart Contract for Boardroom Voting with Maximum Voter Privacy},
Author={McCorry, Patrick and Shahandashti, Siamak F. and Hao, Feng},
Url={http://fc17.ifca.ai/preproceedings/paper_80.pdf},
Year={2017},
Booktitle={Proceedings of Financial Cryptography and Data Security},
Organization={International Financial Cryptography Association}
}
@article{vigna13fibonacci,
Author = {Sebastiano Vigna},
Bibsource = {dblp computer science bibliography, http://dblp.org},
Biburl = {http://dblp.uni-trier.de/rec/bib/journals/corr/Vigna13},
Journal = {CoRR},
Timestamp = {Mon, 06 Jan 2014 15:10:41 +0100},
Title = {Fibonacci Binning},
Url = {http://arxiv.org/abs/1312.3749},
Volume = {abs/1312.3749},
Year = {2013},
Bdsk-Url-1 = {http://arxiv.org/abs/1312.3749}}
@misc{wiki:ricochet,
Author = {Wikipedia},
Note = {[Online; accessed 28-February-2017]},
Title = {Ricochet (software) --- Wikipedia{,} The Free Encyclopedia},
Url = {https://en.wikipedia.org/w/index.php?title=Ricochet_(software)&oldid=755044411},
Year = {2016},
Bdsk-Url-1 = {https://en.wikipedia.org/w/index.php?title=Ricochet_(software)&oldid=755044411}}
@article{darknet,
Author = {De Domenico, Manlio and Arenas, Alex},
Doi = {10.1103/PhysRevE.95.022313},
Issue = {2},
Journal = {Phys. Rev. E},
Month = {Feb},
Numpages = {10},
Pages = {022313},
Publisher = {American Physical Society},
Title = {Modeling structure and resilience of the dark network},
Url = {http://link.aps.org/doi/10.1103/PhysRevE.95.022313},
Volume = {95},
Year = {2017},
Bdsk-Url-1 = {http://link.aps.org/doi/10.1103/PhysRevE.95.022313},
Bdsk-Url-2 = {http://dx.doi.org/10.1103/PhysRevE.95.022313}}
@inproceedings{wu2006query,
Author = {Wu, Ping and Wen, Ji-Rong and Liu, Huan and Ma, Wei-Ying},
Booktitle = {Data Engineering, 2006. ICDE'06. Proceedings of the 22nd International Conference on},
Organization = {IEEE},
Pages = {47--47},
Title = {Query selection techniques for efficient crawling of structured web sources},
Year = {2006}}
@article{borgatti1998network,
Author = {Borgatti, Stephen P and Jones, Candace and Everett, Martin G},
Journal = {Connections},
Number = {2},
Pages = {27--36},
Title = {Network measures of social capital},
Volume = {21},
Year = {1998}}
@misc{wiki:torchat,
Author = {Wikipedia},
Note = {[Online; accessed 28-February-2017]},
Title = {TorChat --- Wikipedia{,} The Free Encyclopedia},
Url = {https://en.wikipedia.org/w/index.php?title=TorChat&oldid=728783759},
Year = {2016},
Bdsk-Url-1 = {https://en.wikipedia.org/w/index.php?title=TorChat&oldid=728783759}}
@misc{wiki:tormessenger,
Author = {Wikipedia},
Note = {[Online; accessed 28-February-2017]},
Title = {Tor (anonymity network) --- Wikipedia{,} The Free Encyclopedia},
Url = {https://en.wikipedia.org/w/index.php?title=Tor_(anonymity_network)#Tor_Messenger&oldid=767770868},
Year = {2017},
Bdsk-Url-1 = {https://en.wikipedia.org/w/index.php?title=Tor_(anonymity_network)#Tor_Messenger&oldid=767770868}}
@techreport{pagerank,
Abstract = {The importance of a Web page is an inherently subjective matter, which depends on the readers interests, knowledge and attitudes. But there is still much that can be said objectively about the relative importance of Web pages. This paper describes PageRank, a mathod for rating Web pages objectively and mechanically, effectively measuring the human interest and attention devoted to them. We compare PageRank to an idealized random Web surfer. We show how to efficiently compute PageRank for large numbers of pages. And, we show how to apply PageRank to search and to user navigation.},
Author = {Lawrence Page and Sergey Brin and Rajeev Motwani and Terry Winograd},
Institution = {Stanford InfoLab},
Month = {November},
Note = {Previous number = SIDL-WP-1999-0120},
Number = {1999-66},
Publisher = {Stanford InfoLab},
Title = {The PageRank Citation Ranking: Bringing Order to the Web.},
Type = {Technical Report},
Url = {http://ilpubs.stanford.edu:8090/422/},
Year = {1999},
Bdsk-Url-1 = {http://ilpubs.stanford.edu:8090/422/}}
@book{everton2012disrupting,
Author = {Everton, Sean F},
Publisher = {Cambridge University Press},
Title = {Disrupting dark networks},
Volume = {34},
Year = {2012}}
@article{broder2000graph,
Author = {Broder, Andrei and Kumar, Ravi and Maghoul, Farzin and Raghavan, Prabhakar and Rajagopalan, Sridhar and Stata, Raymie and Tomkins, Andrew and Wiener, Janet},
Journal = {Computer networks},
Number = {1},
Pages = {309--320},
Publisher = {Elsevier},
Title = {Graph structure in the web},
Volume = {33},
Year = {2000}}
@article{rfc7686,
Author = {Appelbaum, Jacob and Muffet, Alex},
Issn = {2070-1721},
Journal = {Internet Engineering Task Force RFC},
Month = {Oct},
Title = {The ``.onion'' Special-Use Domain Name},
Url = {https://tools.ietf.org/html/rfc7686},
Volume = {7686},
Year = {2015},
Bdsk-Url-1 = {https://tools.ietf.org/html/rfc7686}}
@article{clauset2009power,
Author = {Clauset, Aaron and Shalizi, Cosma Rohilla and Newman, Mark EJ},
Journal = {SIAM review},
Number = {4},
Pages = {661--703},
Publisher = {SIAM},
Title = {Power-law distributions in empirical data},
Volume = {51},
Year = {2009}}
@article{meusel2015graph,
Author = {Meusel, Robert and Vigna, Sebastiano and Lehmberg, Oliver and Bizer, Christian},
Journal = {The Journal of Web Science},
Number = {1},
Title = {The Graph Structure in the Web--Analyzed on Different Aggregation Levels},
Volume = {1},
Year = {2015}}
@inproceedings{lehmberg2014graph,
Author = {Lehmberg, Oliver and Meusel, Robert and Bizer, Christian},
Booktitle = {Proceedings of the 2014 ACM conference on Web science},
Organization = {ACM},
Pages = {119--128},
Title = {Graph structure in the web: aggregated by pay-level domain},
Year = {2014}}
@inproceedings{Meusel2014,
Acmid = {2576928},
Address = {New York, NY, USA},
Author = {Meusel, Robert and Vigna, Sebastiano and Lehmberg, Oliver and Bizer, Christian},
Booktitle = {Proceedings of the 23rd International Conference on World Wide Web},
Doi = {10.1145/2567948.2576928},
Isbn = {978-1-4503-2745-9},
Keywords = {graph analysis, network analysis, web graph, web mining, world wide web},
Location = {Seoul, Korea},
Numpages = {6},
Pages = {427--432},
Publisher = {ACM},
Series = {WWW '14 Companion},
Title = {Graph Structure in the Web --- Revisited: A Trick of the Heavy Tail},
Url = {http://doi.acm.org/10.1145/2567948.2576928},
Year = {2014},
Bdsk-Url-1 = {http://doi.acm.org/10.1145/2567948.2576928},
Bdsk-Url-2 = {http://dx.doi.org/10.1145/2567948.2576928}}
@article{Serrano2007,
Acmid = {1255442},
Address = {New York, NY, USA},
Articleno = {10},
Author = {Serrano, M. \'{A}ngeles and Maguitman, Ana and Bogu\~{n}\'{a}, Mari\'{a}n and Fortunato, Santo and Vespignani, Alessandro},
Doi = {10.1145/1255438.1255442},
Issn = {1559-1131},
Issue_Date = {August 2007},
Journal = {ACM Trans. Web},
Keywords = {Web graph structure, Web measurement, crawler biases, statistical analysis},
Month = aug,
Number = {2},
Publisher = {ACM},
Title = {Decoding the Structure of the WWW: A Comparative Analysis of Web Crawls},
Url = {http://doi.acm.org/10.1145/1255438.1255442},
Volume = {1},
Year = {2007},
Bdsk-Url-1 = {http://doi.acm.org/10.1145/1255438.1255442},
Bdsk-Url-2 = {http://dx.doi.org/10.1145/1255438.1255442}}
@inproceedings{li2004first,
Author = {Li, Lun and Alderson, David and Willinger, Walter and Doyle, John},
Booktitle = {ACM SIGCOMM Computer Communication Review},
Number = {4},
Organization = {ACM},
Pages = {3--14},
Title = {A first-principles approach to understanding the internet's router-level topology},
Volume = {34},
Year = {2004}}
@article{bollobas2004robustness,
Author = {Bollob{\'a}s, B{\'e}la and Riordan, Oliver},
Journal = {Internet Mathematics},
Number = {1},
Pages = {1--35},
Publisher = {Taylor \& Francis},
Title = {Robustness and vulnerability of scale-free random graphs},
Volume = {1},
Year = {2004}}
@article{barabasi1999emergence,
Author = {Barab{\'a}si, Albert-L{\'a}szl{\'o} and Albert, R{\'e}ka},
Journal = {science},
Number = {5439},
Pages = {509--512},
Publisher = {American Association for the Advancement of Science},
Title = {Emergence of scaling in random networks},
Volume = {286},
Year = {1999}}
@article{willinger2013internet,
Author = {Willinger, Walter and Roughan, Matthew},
Journal = {ACM SIGCOMM eBook: Recent Advances in Networking},
Title = {Internet topology research redux},
Year = {2013}}
@article{willinger2009mathematics,
Author = {Willinger, Walter and Alderson, David and Doyle, John C},
Journal = {Notices of the AMS},
Number = {5},
Pages = {586--599},
Title = {Mathematics and the internet: A source of enormous confusion and great potential},
Volume = {56},
Year = {2009}}
@article{pansiot1998routes,
Author = {Pansiot, Jean-Jacques and Grad, Dominique},
Journal = {ACM SIGCOMM Computer Communication Review},
Number = {1},
Pages = {41--50},
Publisher = {ACM},
Title = {On routes and multicast trees in the Internet},
Volume = {28},
Year = {1998}}
@mastersthesis{jovanovic2001modeling,
Author = {Jovanovic, Mihajlo A},
School = {University of Cincinnati},
Title = {Modeling large-scale peer-to-peer networks and a case study of Gnutella},
Year = {2001}}
@inproceedings{kumar2000web,
Author = {Kumar, Ravi and Raghavan, Prabhakar and Rajagopalan, Sridhar and Sivakumar, Dandapani and Tompkins, Andrew and Upfal, Eli},
Booktitle = {Proceedings of the nineteenth ACM SIGMOD-SIGACT-SIGART symposium on Principles of database systems},
Organization = {ACM},
Pages = {1--10},
Title = {The Web as a graph},
Year = {2000}}
@article{barabasi2000scale,
Author = {Barab{\'a}si, Albert-L{\'a}szl{\'o} and Albert, R{\'e}ka and Jeong, Hawoong},
Journal = {Physica A: Statistical Mechanics and its Applications},
Number = {1},
Pages = {69--77},
Publisher = {Elsevier},
Title = {Scale-free characteristics of random networks: the topology of the world-wide web},
Volume = {281},
Year = {2000}}
@article{siganos2003power,
Author = {Siganos, Georgos and Faloutsos, Michalis and Faloutsos, Petros and Faloutsos, Christos},
Journal = {IEEE/ACM Transactions on Networking (TON)},
Number = {4},
Pages = {514--524},
Publisher = {IEEE Press},
Title = {Power laws and the AS-level internet topology},
Volume = {11},
Year = {2003}}
@inproceedings{biryukov2013trawling,
Author = {Biryukov, Alex and Pustogarov, Ivan and Weinmann, Ralf-Philipp},
Booktitle = {Security and Privacy (SP), 2013 IEEE Symposium on},
Organization = {IEEE},
Pages = {80--94},
Title = {Trawling for tor hidden services: Detection, measurement, deanonymization},
Year = {2013}}
@article{albert2001physics,
Author = {Albert-L{\'a}szl{\'o} Barab{\'a}si, July},
Journal = {Physics Web http://www.physicsweb.org/article/world/14/7/09},
Title = {The physics of the Web},
Year = {2001}}
@article{cohen2001breakdown,
Author = {Cohen, Reuven and Erez, Keren and Ben-Avraham, Daniel and Havlin, Shlomo},
Journal = {Physical review letters},
Number = {16},
Pages = {3682},
Publisher = {APS},
Title = {Breakdown of the Internet under intentional attack},
Volume = {86},
Year = {2001}}
@article{albert2000error,
Author = {Albert, R{\'e}ka and Jeong, Hawoong and Barab{\'a}si, Albert-L{\'a}szl{\'o}},
Journal = {nature},
Number = {6794},
Pages = {378--382},
Publisher = {Nature Publishing Group},
Title = {Error and attack tolerance of complex networks},
Volume = {406},
Year = {2000}}
@article{adamic2000power,
Author = {Adamic, Lada A and Huberman, Bernardo A},
Journal = {Science},
Number = {5461},
Pages = {2115--2115},
Publisher = {American Association for the Advancement of Science},
Title = {Power-law distribution of the world wide web},
Volume = {287},
Year = {2000}}
@misc{tormetrics,
Author = {The Tor Project},
Month = {January},
Title = {TorMetrics --- Unique .onion addresses},
Url = {https://metrics.torproject.org/hidserv-dir-onions-seen.html},
Year = {2017},
Bdsk-Url-1 = {https://metrics.torproject.org/hidserv-dir-onions-seen.html}}

BIN
casper4/papers/casper-economics/figs/cs.pdf Normal file
View File

Binary file not shown.

236
casper4/papers/casper-economics/nips10submit_e.sty Normal file
View File

@ -0,0 +1,236 @@
%%%% NIPS Macros (LaTex)
%%%% Style File
%%%% Dec 12, 1990 Rev Aug 14, 1991; Sept, 1995; April, 1997; April, 1999
% This file can be used with Latex2e whether running in main mode, or
% 2.09 compatibility mode.
%
% If using main mode, you need to include the commands
% \documentclass{article}
% \usepackage{nips10submit_e,times}
% as the first lines in your document. Or, if you do not have Times
% Roman font available, you can just use
% \documentclass{article}
% \usepackage{nips10submit_e}
% instead.
%
% If using 2.09 compatibility mode, you need to include the command
% \documentstyle[nips10submit_09,times]{article}
% as the first line in your document. Or, if you do not have Times
% Roman font available, you can include the command
% \documentstyle[nips10submit_09]{article}
% instead.
% Change the overall width of the page. If these parameters are
% changed, they will require corresponding changes in the
% maketitle section.
%
\usepackage{eso-pic} % used by \AddToShipoutPicture
\renewcommand{\topfraction}{0.95} % let figure take up nearly whole page
\renewcommand{\textfraction}{0.05} % let figure take up nearly whole page
% Define nipsfinal, set to true if nipsfinalcopy is defined
\newif\ifnipsfinal
\nipsfinalfalse
\def\nipsfinalcopy{\nipsfinaltrue}
\font\nipstenhv = phvb at 8pt % *** IF THIS FAILS, SEE nips10submit_e.sty ***
% Specify the dimensions of each page
\setlength{\paperheight}{11in}
\setlength{\paperwidth}{8.5in}
\oddsidemargin .5in % Note \oddsidemargin = \evensidemargin
\evensidemargin .5in
\marginparwidth 0.07 true in
%\marginparwidth 0.75 true in
%\topmargin 0 true pt % Nominal distance from top of page to top of
%\topmargin 0.125in
\topmargin -0.625in
\addtolength{\headsep}{0.25in}
\textheight 9.0 true in % Height of text (including footnotes & figures)
\textwidth 5.5 true in % Width of text line.
\widowpenalty=10000
\clubpenalty=10000
% \thispagestyle{empty} \pagestyle{empty}
\flushbottom \sloppy
% We're never going to need a table of contents, so just flush it to
% save space --- suggested by drstrip@sandia-2
\def\addcontentsline#1#2#3{}
% Title stuff, taken from deproc.
\def\maketitle{\par
\begingroup
\def\thefootnote{\fnsymbol{footnote}}
\def\@makefnmark{\hbox to 0pt{$^{\@thefnmark}$\hss}} % for perfect author
% name centering
% The footnote-mark was overlapping the footnote-text,
% added the following to fix this problem (MK)
\long\def\@makefntext##1{\parindent 1em\noindent
\hbox to1.8em{\hss $\m@th ^{\@thefnmark}$}##1}
\@maketitle \@thanks
\endgroup
\setcounter{footnote}{0}
\let\maketitle\relax \let\@maketitle\relax
\gdef\@thanks{}\gdef\@author{}\gdef\@title{}\let\thanks\relax}
% The toptitlebar has been raised to top-justify the first page
% Title (includes both anonimized and non-anonimized versions)
\def\@maketitle{\vbox{\hsize\textwidth
\linewidth\hsize \vskip 0.1in \toptitlebar \centering
{\LARGE\bf \@title\par} \bottomtitlebar % \vskip 0.1in % minus
\ifnipsfinal
\def\And{\end{tabular}\hfil\linebreak[0]\hfil
\begin{tabular}[t]{c}\bf\rule{\z@}{24pt}\ignorespaces}%
\def\AND{\end{tabular}\hfil\linebreak[4]\hfil
\begin{tabular}[t]{c}\bf\rule{\z@}{24pt}\ignorespaces}%
\begin{tabular}[t]{c}\bf\rule{\z@}{24pt}\@author\end{tabular}%
\else
\begin{tabular}[t]{c}\bf\rule{\z@}{24pt}
Anonymous Author(s) \\
Affiliation \\
Address \\
\texttt{email} \\
\end{tabular}%
\fi
\vskip 0.3in minus 0.1in}}
\renewenvironment{abstract}{\vskip.075in\centerline{\large\bf
Abstract}\vspace{0.5ex}\begin{quote}}{\par\end{quote}\vskip 1ex}
% sections with less space
\def\section{\@startsection {section}{1}{\z@}{-2.0ex plus
-0.5ex minus -.2ex}{1.5ex plus 0.3ex
minus0.2ex}{\large\bf\raggedright}}
\def\subsection{\@startsection{subsection}{2}{\z@}{-1.8ex plus
-0.5ex minus -.2ex}{0.8ex plus .2ex}{\normalsize\bf\raggedright}}
\def\subsubsection{\@startsection{subsubsection}{3}{\z@}{-1.5ex
plus -0.5ex minus -.2ex}{0.5ex plus
.2ex}{\normalsize\bf\raggedright}}
\def\paragraph{\@startsection{paragraph}{4}{\z@}{1.5ex plus
0.5ex minus .2ex}{-1em}{\normalsize\bf}}
\def\subparagraph{\@startsection{subparagraph}{5}{\z@}{1.5ex plus
0.5ex minus .2ex}{-1em}{\normalsize\bf}}
\def\subsubsubsection{\vskip
5pt{\noindent\normalsize\rm\raggedright}}
% Footnotes
\footnotesep 6.65pt %
\skip\footins 9pt plus 4pt minus 2pt
\def\footnoterule{\kern-3pt \hrule width 12pc \kern 2.6pt }
\setcounter{footnote}{0}
% Lists and paragraphs
\parindent 0pt
\topsep 4pt plus 1pt minus 2pt
\partopsep 1pt plus 0.5pt minus 0.5pt
\itemsep 2pt plus 1pt minus 0.5pt
\parsep 2pt plus 1pt minus 0.5pt
\parskip .5pc
%\leftmargin2em
\leftmargin3pc
\leftmargini\leftmargin \leftmarginii 2em
\leftmarginiii 1.5em \leftmarginiv 1.0em \leftmarginv .5em
%\labelsep \labelsep 5pt
\def\@listi{\leftmargin\leftmargini}
\def\@listii{\leftmargin\leftmarginii
\labelwidth\leftmarginii\advance\labelwidth-\labelsep
\topsep 2pt plus 1pt minus 0.5pt
\parsep 1pt plus 0.5pt minus 0.5pt
\itemsep \parsep}
\def\@listiii{\leftmargin\leftmarginiii
\labelwidth\leftmarginiii\advance\labelwidth-\labelsep
\topsep 1pt plus 0.5pt minus 0.5pt
\parsep \z@ \partopsep 0.5pt plus 0pt minus 0.5pt
\itemsep \topsep}
\def\@listiv{\leftmargin\leftmarginiv
\labelwidth\leftmarginiv\advance\labelwidth-\labelsep}
\def\@listv{\leftmargin\leftmarginv
\labelwidth\leftmarginv\advance\labelwidth-\labelsep}
\def\@listvi{\leftmargin\leftmarginvi
\labelwidth\leftmarginvi\advance\labelwidth-\labelsep}
\abovedisplayskip 7pt plus2pt minus5pt%
\belowdisplayskip \abovedisplayskip
\abovedisplayshortskip 0pt plus3pt%
\belowdisplayshortskip 4pt plus3pt minus3pt%
% Less leading in most fonts (due to the narrow columns)
% The choices were between 1-pt and 1.5-pt leading
%\def\@normalsize{\@setsize\normalsize{11pt}\xpt\@xpt} % got rid of @ (MK)
\def\normalsize{\@setsize\normalsize{11pt}\xpt\@xpt}
\def\small{\@setsize\small{10pt}\ixpt\@ixpt}
\def\footnotesize{\@setsize\footnotesize{10pt}\ixpt\@ixpt}
\def\scriptsize{\@setsize\scriptsize{8pt}\viipt\@viipt}
\def\tiny{\@setsize\tiny{7pt}\vipt\@vipt}
\def\large{\@setsize\large{14pt}\xiipt\@xiipt}
\def\Large{\@setsize\Large{16pt}\xivpt\@xivpt}
\def\LARGE{\@setsize\LARGE{20pt}\xviipt\@xviipt}
\def\huge{\@setsize\huge{23pt}\xxpt\@xxpt}
\def\Huge{\@setsize\Huge{28pt}\xxvpt\@xxvpt}
\def\toptitlebar{\hrule height4pt\vskip .25in\vskip-\parskip}
\def\bottomtitlebar{\vskip .29in\vskip-\parskip\hrule height1pt\vskip
.09in} %
%Reduced second vskip to compensate for adding the strut in \@author
% Vertical Ruler
% This code is, largely, from the CVPR 2010 conference style file
% ----- define vruler
\makeatletter
\newbox\nipsrulerbox
\newcount\nipsrulercount
\newdimen\nipsruleroffset
\newdimen\cv@lineheight
\newdimen\cv@boxheight
\newbox\cv@tmpbox
\newcount\cv@refno
\newcount\cv@tot
% NUMBER with left flushed zeros \fillzeros[<WIDTH>]<NUMBER>
\newcount\cv@tmpc@ \newcount\cv@tmpc
\def\fillzeros[#1]#2{\cv@tmpc@=#2\relax\ifnum\cv@tmpc@<0\cv@tmpc@=-\cv@tmpc@\fi
\cv@tmpc=1 %
\loop\ifnum\cv@tmpc@<10 \else \divide\cv@tmpc@ by 10 \advance\cv@tmpc by 1 \fi
\ifnum\cv@tmpc@=10\relax\cv@tmpc@=11\relax\fi \ifnum\cv@tmpc@>10 \repeat
\ifnum#2<0\advance\cv@tmpc1\relax-\fi
\loop\ifnum\cv@tmpc<#1\relax0\advance\cv@tmpc1\relax\fi \ifnum\cv@tmpc<#1 \repeat
\cv@tmpc@=#2\relax\ifnum\cv@tmpc@<0\cv@tmpc@=-\cv@tmpc@\fi \relax\the\cv@tmpc@}%
% \makevruler[<SCALE>][<INITIAL_COUNT>][<STEP>][<DIGITS>][<HEIGHT>]
\def\makevruler[#1][#2][#3][#4][#5]{\begingroup\offinterlineskip
\textheight=#5\vbadness=10000\vfuzz=120ex\overfullrule=0pt%
\global\setbox\nipsrulerbox=\vbox to \textheight{%
{\parskip=0pt\hfuzz=150em\cv@boxheight=\textheight
\cv@lineheight=#1\global\nipsrulercount=#2%
\cv@tot\cv@boxheight\divide\cv@tot\cv@lineheight\advance\cv@tot2%
\cv@refno1\vskip-\cv@lineheight\vskip1ex%
\loop\setbox\cv@tmpbox=\hbox to0cm{{\nipstenhv\hfil\fillzeros[#4]\nipsrulercount}}%
\ht\cv@tmpbox\cv@lineheight\dp\cv@tmpbox0pt\box\cv@tmpbox\break
\advance\cv@refno1\global\advance\nipsrulercount#3\relax
\ifnum\cv@refno<\cv@tot\repeat}}\endgroup}%
\makeatother
% ----- end of vruler
% \makevruler[<SCALE>][<INITIAL_COUNT>][<STEP>][<DIGITS>][<HEIGHT>]
\def\nipsruler#1{\makevruler[12pt][#1][1][3][0.993\textheight]\usebox{\nipsrulerbox}}
\AddToShipoutPicture{%
\ifnipsfinal\else
\nipsruleroffset=\textheight
\advance\nipsruleroffset by -3.7pt
\color[rgb]{.7,.7,.7}
\AtTextUpperLeft{%
\put(\LenToUnit{-35pt},\LenToUnit{-\nipsruleroffset}){%left ruler
\nipsruler{\nipsrulercount}}
}
\fi
}