bitcoin-incentives.tex

% Default course lecture note template by asp 
\documentclass[letterpaper]{article}
\usepackage[utf8]{inputenc}
\usepackage[english]{babel}
\usepackage[top=3cm, bottom=3cm, left=3.85cm, right=3.85cm]{geometry}
\usepackage[onehalfspacing]{setspace}
\usepackage{hyperref}
\usepackage[usenames,dvipsnames]{color}
\usepackage{gitinfo}

\title{Bitcoin Incentives}
\author{Andrew Poelstra}
\author{Bryan Bishop}
\date{\gitAuthorDate{} (commit \texttt{\gitAbbrevHash)}}

\begin{document}

\maketitle

\paragraph{Status.} This document is a work in progress and is missing large
sections of text. Bug reports should be communicated at
\url{https://github.com/kanzure/bitcoin-incentives}.

\section{Introduction}

``[It is hard to] figure out how to bootstrap an incentives model, because
there's no incentive except for the virtual currency payments, and yet the
value of the virtual currency payments only matters if it's secure, and it's
only secure if the incentive mechanism works.....'' - Andrew Miller

Bitcoin is a novel p2p payment network which performs transaction processing
without the need for any centralized, trusted third party. Bitcoin achieves
this through a decentralized consensus history of transactions provided to
every participant. This history is required to confirm the absence of a prior
transaction. However, history at other edges of the network is unavailable to
other nodes, because of propagation delays and speed-of-light constraints.
Bitcoin provides some rules and incentives for maintaining a consensus history
under these (and other) physical constraints. A complete mechanical or physical
understanding of Bitcoin has yet to be introduced and is not offered here. This
document focuses on an enumeration of incentives and constraints involved in
Bitcoin.

Here is an enumeration of various incentives that exist in the Bitcoin software
and p2p network.

Some incentives are much stronger than others, by orders of magnitude. There
could eventually be a rating scheme or a comparison method.

Some of these incentives are implemented in code and are enforced by consensus
rules. Other incentives are based not on code but instead on the effects of the
software, or implications derived from the software, independent of whether or
not the incentive is ``hard coded''.

Some of these incentives have been observed in the wild, while others have
persistent presence, while different others might be only somewhat theoretical
and not directly observed yet.

Bitcoin does this, and here's why.

\section{Definitions}

\paragraph{Incentive} An incentive in a p2p system exists when there is an
opportunity cost to inaction. Alternatively, an incentive is a set of features
of an anticipated or hypothetical environment, such that the reward for taking
some action (including whatever future constraints or consequences this locally
imposes on future behavior) is higher than the reward for not taking that
action, relative to how much higher it would be if those features were absent.

\paragraph{Byzantine failure} This is a type of failure in distributed systems
in which components of a system fail in arbitrary ways. These failures can
include stopping or crashing as well as processing requests incorrectly,
corrupting local state, and producing incorrect or inconsistent outputs, as
well as a variety of other amusing failure modes.

\paragraph{Sybil attack} An adversary can endlessly create misbehaving nodes in
a p2p network, especially when the existing nodes on the network are already
programmed to accept new incoming connections from unknowns.

\paragraph{p2p} Peer-to-peer.

\section{Preliminaries}

\subsection{Satoshi's Byzantine Generals' Problem}

(This wording is based on \url{http://bitcoin.org/byzantine.html} originally.)

A number of Byzantine Generals each have a computer and want to attack the
King's Wi-Fi by brute forcing the password, which they've learned is a certain
number of characters in length. Once they stimulate the network to generate a
packet, they must crack the password within a limited time to break in and
erase the logs, lest they be discovered. They only have enough CPU power to
crack it fast enough if a majority of them attack at the same time.

They don't particularly care when the attack will be, just that they agree. It
has been decided that anyone who feels like it will announce an attack time,
which we'll call the ``plan'', and whatever plan is heard first will be the
official plan. The problem is that the network is not instantaneous, and if two
generals announce different plans at close to the same time, some may hear one
first and others hear the other first.

They use a proof-of-work chain to solve the problem. Once each general receives
whatever plan he hears first, he sets his computer to solve a difficult
hash-based proof-of-work problem that includes the plan in its hash. The
proof-of-work is difficult enough that with all of them working at once, it's
expected to take 10 minutes before one of them finds a solution and broadcasts
it to the network. Once received, everyone adjusts the hash in their
proof-of-work computation to include the first solution, so that when they find
the next proof-of-work, it chains after the first one. If anyone was working on
a different plan, they switch to this one, because its proof-of-work chain is
now longer.

After about two hours, the plan should be hashed by a chain of 12
proofs-of-work. Every general, just by verifying the difficulty of the
proof-of-work chain, can estimate how much parallel CPU power per hour was
expended on it and see that it must have required the majority of the computers
to produce in the allotted time. At the least, most of them had to have seen
the plan, since the proof-of-work is proof that they worked on it. If the CPU
power exhibited by the proof-of-work is sufficient to crack the password, they
can safely attack at the agreed time.

\subsection{Maaku's Physical Explanation of Bitcoin and Proof-of-Work}

Proof-of-Work (PoW) works because of the economic restriction provided by the
second law of thermodynamics. Even though you can't know you're in the
consensus set, you can put a raw economic cost on the probability of you being
tricked.  Bitcoin uses proof-of-work to tie Bitcoin consensus to a
fundamentally scarce resource, namely entropy. It is possible to use another
physically scarce resource instead, but there is no alternative to the
universal scarcity of entropy. As maaku puts it, ``I could be an AI trapped in a
simulation with no knowledge of the outside world other than the foundational
laws of physics, and from that be able to assert the validity of
proof-of-work.''

\section{Incentives}

\begin{enumerate}
\item Block subsidy incentive to miners for every block they mine.

\item Block transaction fees provide an incentive for miners to mine blocks.

\item Miner transaction fee incentive is somewhat limited by the byte size of
each transaction.

\item Miners have an incentive to publish blocks as quickly as possible because
of the lottery race they participate in against other miners who may also have
a valid block, or who may soon find a block.

\item Miners have an incentive to limit the size of their blocks so as to
minimize the time it takes for their block to saturate the network or reach
every node in the p2p network.

\item Various vague incentives about miners including any transaction, because
of the benefit of providing a working system, compared to rejecting the
majority of transactions and losing users that might pay transaction fees or
pay to other users that might pay transaction fees.

\item Miners have an incentive to include transactions with high fees not only
because ``more money is good'' but also because it removes the pool of available
transaction fees that other miners could benefit from.

\item Users have an incentive to include transaction fees to get transactions
processed faster than ``normal''. (?)

\item Incentives to provide accurate timestamps. These are roughly:
\begin{enumerate}
\item Not doing this has nearly no benefit: only every 2016th block affects the
difficulty, and if the timestamp is wrong by more than 2 hours then other nodes
won't relay the block (so maximum ``safe'' skew is 0.60\%).
\item Because other have inaccurate clocks, any skew will increase the risk that
your block is not relayed. (Though we do observe in fact blocks with wildly wrong
timestamps, so this is apparently not a concern in practice.)
\end{enumerate}

\item Incentives to relay transactions.

\item Incentives to relay blocks.

\item Incentives to verify transactions.

\item Incentives to maintain a mempool.

\item Incentives to not relay certain transactions.

\item Incentives to switch between forks.

\item Incentives to not switch between forks.

\item Incentives to broadcast blocks once found.

\item Incentives to provide initial block downloads.

\item ...the effect a fluctuating price can have on mining - price drops mean offline miners, which means `dark hashpower'. A bubble can result in miners overbuying, anticipating a sellout at much higher prices, which can also affect the mining ecosystem when the bubble doesn't reach the anticipated heights.

\end{enumerate}

\section{Conclusion}

\paragraph{Thank you.} Many individuals have both directly and indirectly
contributed to the ideas presented in this document, including: ...

\begin{thebibliography}{9}
\bibitem{satoshi} \url{https://www.bitcoin.org/bitcoin.pdf}
\end{thebibliography}

\end{document}