zold 0.8 → 0.9

data/wp/wp.tex

@@ -1,11 +1,17 @@
 \documentclass[11pt,oneside]{article}
 \usepackage[utf8]{inputenc}
 \usepackage[american]{babel}
-\usepackage{setspace}
+\usepackage{bookmark}
 \usepackage{microtype}
-\usepackage{mathpazo} % Palantino font
+% \usepackage{mathpazo} % Palantino font
 \usepackage{mdframed}
 \usepackage{pgfplots}
+\usepackage{hyperref}
+\usepackage[style=authoryear,sorting=nyt,backend=biber,
+  hyperref=true,abbreviate=true,
+  maxcitenames=1,maxbibnames=1]{biblatex}
+  \renewbibmacro{in:}{}
+  \addbibresource{main.bib}
 \usepackage{minted}
   \setminted{fontsize=\small}
   \setminted{breaklines}
@@ -17,90 +23,199 @@
 \newcommand\dd[1]{\colorbox{gray!30}{\texttt{#1}}}
 \usepackage{hyperref}
   \hypersetup{colorlinks=true,allcolors=blue!40!black}
-\pagestyle{empty}
-\setstretch{1.1}
 \setlength{\topskip}{6pt}
 \setlength{\parindent}{0pt} % indent first line
 \setlength{\parskip}{6pt} % before par
 
-\title{\includegraphics[scale=0.05]{logo.png}\\Zold: a Light-Weight Crypto Currency}
-\author{Yegor Bugayenko\\\texttt{yegor@zold.io}}
+\title{\includegraphics[scale=0.05]{logo.png}\\Zold: A Fast Cryptocurrency for Micro Payments}
+\author{Yegor Bugayenko\\\texttt{yegor256@gmail.com}}
 
 \begin{document}
 \raggedbottom
 
 \maketitle
 \begin{abstract}
-The world is hyped about digital currencies now. Why not create a new one,
-which will implement a different set of architectural principles? Zold is
-an \emph{experimental} solution that enables distributed transactions between
-anonymous users. Its core ``proof of work'' principle is borrowed from Bitcoin's Blockchain,
-while the rest of the architecture is new.
+In the last few years digital currencies successfully demonstrated
+their ability to become an alternative financial instrument in many
+different markets. Most of the technologies available at the moment are
+based on the principles of Blockchain architecture, including the
+dominating currencies like Bitcoin and Etherium. Despite its
+popularity, Blockchain is not the only possible solution and is not the best
+for fast micro-payments.
+Zold is an \emph{experimental} alternative that enables distributed transactions between
+anonymous users, making micro-payments financially feasible.
+It borrows the ``proof of work'' principle from Bitcoin,
+and suggests a different architecture for digital wallets maintenance.
 \end{abstract}
 
-\colorbox{yellow}{It's a draft! Don't show it to anyone yet.}
-
 \section{Motivation}
 
-Bitcoin, the first decentralized digital currency, was released in
-January 2009. Since then a number of similar Blockchain-based products have been
-created, including Etherium, Litecoin, and others. \colorbox{yellow}{links} There were other solutions,
-not based on Blockchain, including IOTA, and others. \colorbox{yellow}{links}
-
-Zold is also a decentralized digital currency that maintains its transactions
-in an unpredicable amount of zero-trust server nodes, trying to guarantee
-data consistency. However, the architecture of Zold is not based on Blockchain
-principles. The development of Zold was motivated by the desire to overcome
-a few obvious disadvantages of existing solutions.
-
-First, the speed of transaction processing is rather low. \colorbox{yellow}{proof?}
-
-Second, mining commissions are high. \colorbox{yellow}{proof?}
-
-Third, the technology is too complex. \colorbox{yellow}{proof?}
-
-Zold was created as an attempt to resolve these mentioned problems
-of existing digital currencies.
+Bitcoin, the first decentralized digital currency, was released in January 2009~\parencite{nakamoto2008}.
+During a few following years ``a libertarian fairy tale'' and ``a simple Silicon Valley exercise in hype''
+turned into ``a catalyst to reshape the financial system in ways that are more
+powerful for individuals and businesses alike,'' according to \textcite{andreessen2014}.
+At the moment, as~\textcite{van2014} claimed, ``the question is not whether Bitcoin has value; it already does.
+The question is whether the efficiencies of a cybercurrency
+like Bitcoin can be merged with the certainties of an honest central bank.''
+
+The core component of Bitcoin is the Blockchain technology, which
+``ensures the elimination of the double-spend problem, with the help
+of public-key cryptography'' and ``coins are transferred by the
+digital signature of a hash''~\parencite{pilkington2016}.
+Very soon after the Bitcoin invention similar products were introduced,
+which were also based on the principles of Blockchain, such as
+Etherium~\parencite{buterin2013}.
+
+Even though Blockchain is a sound solution of the double-spending
+problem, there could be other solutions,
+including different ``proof-of'' alternatives.%
+\footnote{%
+  \url{https://goo.gl/aqzf2Q}:
+  ``Proof-of-Burn'': instead of bringing the money together into computer equipment,
+  the owner burns the coins. Here the coins to the address where they are
+  irretrievable. By doing this, the owner gets a privilege to
+  mine on the system.
+  ``Proof-of-Stake'': the coins exist from the start, and
+  the validators get a reward in the form of transaction fees.
+  ``Proof-Of-Capacity'': one pays with the hard drive space. The more
+  is the hard drive space; the more is the probability of mining
+  the next block and earning a reward.
+  ``Proof-of-Elapsed-Time'': one uses Trusted Execution Environment or TEE
+  to ensure a random looter production.
+}
+For example, \textcite{everaere2010} gave
+a summary of them and introduced their own;
+\textcite{boyen2016} described
+``a truly distributed ledger system based on a lean graph of cross-verifying transactions'';
+recently IOTA, a ``tangle-based cryptocurrency,'' was launched~\parencite{popov2017}.
+
+Zold also is a decentralized digital currency that maintains its ledgers
+at an unpredicable amount of anonymous and untrustable server nodes, trying to guarantee
+data consistency. The architecture of Zold is not Blockchain-based.
+The development of Zold was motivated by the desire to overcome
+two obvious disadvantages of the majority of all existing cryptocyrrencies:
+
+The first problem is that transaction processing is rather slow.%
+\footnote{%
+  \url{https://goo.gl/sWiAWc}:
+  ``Current rates for Bitcoin processing
+  speed is 7 transactions per second (tps) while Paypal handles
+  an average of 115 tps and the VISA
+  network has a peak capacity of 47,000 tps (though it currently needs 2000-4000 tps).''
+}
+\textcite{karame2012} says that ``Bitcoin requires tens of minutes to verify a transaction
+and is therefore inappropriate for fast payments.''
+It is inevitable, since
+``processing speed is at odds with the security aspects of the underlying
+proof-of-work based consensus mechanism''~\parencite{kiayias2015}.
+
+The second problem, as noted by~\textcite{popov2017}, is that ``it is not easy to get rid
+of fees in the blockchain infrastructure since they serve
+as an incentive for the creators of blocks.''
+As per~\textcite{moser2015}, ``Bitcoin users are encouraged to
+pay fees to miners, up to 10 cents (of USD) per transaction, irrespective of the
+amount paid'' which especially hurts when transaction amounts are smaller than a dollar.
+Moreover, according to~\textcite{kaskaloglu2014},
+``an increase in transaction fees of Bitcoin is inevitable.''
+
+Thus, the speed is low and the processing fees are high.
+Zold was created as an attempt to resolve these two problems
+of existing Blockchain-based digital currencies.
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \section{Principles}
 
-\textbf{Open Source}.
-Zold is a command line tool. Its entire code base is open source
-and hosted at the GitHub \href{https://github.com/yegor256/zold}{yegor256/zold}
-repository.
+\textbf{No General Ledger}.
+Unlike \emph{all} other crypto currencies, there is no central ledger in Zold.
+Each wallet has its own personal ledger.
+All transactions in each ledger are confirmed by
+\href{https://en.wikipedia.org/wiki/RSA_(cryptosystem)}{RSA signatures} of their owners.
+
+\textbf{Proof of work}.
+Similar to many other digital currencies---including Bitcoin, Etherium, Plancoin, Monero, Trinity, Plancoin, Dero,
+and many others---Zold nodes find consensus by comparing the amount of CPU power invested
+by each of them into finding hash suffixes, performing certain expensive and meaningless calculations.
+
+\textbf{Root Wallet}.
+Zold is a pre-mined%
+\footnote{%
+  \url{https://goo.gl/QBhbcT}:
+  ``A premine or instamine is where the developer or developers don't release
+  the crypto currency in what can be considered a fair manner.
+  Even Bitcoin can be considered to be instamined to a certain extent.
+  A premine is where a developer allocates a certain amount of currency
+  credit to a particular address before releasing the source
+  code to the open community.''
+}
+digital asset, similar to Ripple,%
+\footnote{%
+  \url{https://goo.gl/XAtPH8}:
+  ``When the Ripple network was created, 100 billion XRP was created.
+  The founders gave 80 billion XRP to the Ripple Labs. Ripple Labs
+  will develop the Ripple software, promote the Ripple payment system,
+  give away XRP, and sell XRP.''
+}
+Cardano,
+Stellar,%
+\footnote{%
+  \url{https://goo.gl/CnQQwA}:
+  ``The stellar network started with 100 billion lumens.
+  There is a 1\% p.a. inflation, hence the current total of roughly 103.5 billion lumens.
+  About 18 billion lumens are on the market and the other
+  85 is held by the stellar development foundation.''
+}
+EOS, NEO, Loki,%
+\footnote{%
+  \url{https://goo.gl/By5CR3}:
+  ``Over 7 million Loki is held in escrow for the Founder,
+  Advisor, and Seed allocations. The Founder and Advisor allocations
+  follow a 12 month lockup schedule, where 25\% of each allocation is
+  released every 90 days following mainnet launch. The allocations
+  to Founders and Advisors are remuneration for services rendered to the
+  LAG Foundation Ltd. The Seed allocation follows a similar schedule, with a
+  30\% initial release and 20\% every 90 days until the final release of 10\%.''
+}
+and many others.
+The only way to get ZLD is to receive it from someone else.
+The root wallet belongs to the issuer and may have a negative balance,
+which can grow according to a pre-defined restrictive formula.
+All other wallets may only have positive balances.
+
+\textbf{Taxes}.
+Unlike many other payment systems, Zold doesn't require its users
+to pay transaction fees. Instead, wallets have to pay regular ``taxes'' for the
+service of their maintenances. Taxes amounts depend on the amount
+of transactions in a wallet and the age of the wallet.
 
 \textbf{No Trust}.
 The network of communicating nodes maintains wallets of users.
 Anyone can add a node to the network.
 It is assumed that any node may contain corrupted data, either by mistake or intentionally.
 
-\textbf{Proof of work}.
-Each node, in order to earn trust, must invest its CPU power
-and find hash suffixes, performing certain expensive and meaningless calculations.
-
-\textbf{No General Ledger}.
-There is no central ledger, each wallet has its own personal ledger.
-All transactions in each ledger are confirmed by
-\href{https://en.wikipedia.org/wiki/RSA_(cryptosystem)}{RSA signatures}
-of their owners.
+\textbf{Open Source}.
+Zold is a command line tool. Its entire code base is open source
+and hosted at the GitHub \href{https://github.com/yegor256/zold}{yegor256/zold}
+repository.
 
 \textbf{Capacity}.
 One currency unit is called ZLD.
-One ZLD by convention equals to $2^{24}$ \emph{zents} (16,777,216).
+One ZLD by convention equals to $2^{32}$ \emph{zents} (4,294,967,296).
 All amounts are stored as signed 64-bit integers.
-Thus, the technical capacity of the currency is 549,755,813,888 ZLD (half a trillion).
-
-\textbf{Root Wallet}.
-Zold is a pre-mined currency.
-The only way to get ZLD is to receive it from someone else.
-The root wallet belongs to the issuer and may have a negative balance,
-which can grow according to a pre-defined restrictive formula.
-All other wallets may only have positive balances.
+Thus, the technical capacity of the currency is 2,147,483,648 ZLD (two billion).%
+\footnote{%
+  To compare, the total supply of some crypto currencies is:
+  Bitcoin: 21m BTC,
+  Ethereum;: 100m ETH,
+  Ripple: 100b XRP,
+  Litecoin: 84m LTC,
+  Cardano: 31b ADA,
+  Stellar: 103b XLM,
+  NEO: 100m NEO,
+  Dash: 19m DASH.
+}
 
-\colorbox{yellow}{Let's compare each of these principles with other currencies and highlight similarities.}
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
@@ -111,8 +226,7 @@ The system consists of nodes (server machines), which maintain the data.
 In order to guarantee data consistency among all distributed nodes
 there has to be an algorithm of data segregation.
 Corrupted data must be detected earlier and filtered out as quickly as possible.
-Bitcoin introduced such an algorithm and called it \emph{proof of work}.
-\colorbox{yellow}{link}
+Bitcoin introduced such an algorithm and called it \emph{proof of work}~\parencite{nakamoto2008}.
 
 Its fundamental principle is that each block of data must have a special
 number attached to it, known as \emph{nonce}, which is rather difficult to calculate,
@@ -123,16 +237,15 @@ some data gets corrupted, the amount of CPU power a part of the network
 decides to invest into its nonces calculation would be smaller than what
 the other part of the network invests into legal data. The latter part
 will quickly dominate the former and the nodes with corrupted data will
-be ostracized and eventually ignored.
-\colorbox{yellow}{let's make sure this text is correct and add a link}
+be ostracized and eventually ignored~\parencite{nakamoto2008}.
 
 Zold has borrowed this principle, although modified it. It also requires
 its nodes to invest their CPU power into meaninless and repetative
 calculations just to help us identify which part of the network they belong to:
-corrupted or not. Each Zold node has to calculate its \emph{trust score},
+corrupted or not. Each Zold node has to calculate its \emph{score},
 which is as big as much CPU power the node has invested into its calculation.
 
-Similar to Bitcoin nonces we repetatively calculate cryptographic hashes,
+Similar to Bitcoin nonces, Zold nodes repeatedly calculate cryptographic hashes,
 looking for consecutive zeros inside them. First, in order to calculate a score,
 a node makes the \emph{prefix}, which consists of four parts,
 separated by spaces:
@@ -147,29 +260,28 @@ separated by spaces:
 For example, the prefix may look like this:
 
 \begin{minted}{text}
-2018-05-17T03:50:59Z b2.zold.io 4096 THdonv1E@0000000000000000
+2018-05-17T03:50:59Z b2.zold.io 4096 THdonv1E@abcdabcdabcdabcd
 \end{minted}
 
 Then, the node attempts to append any arbitrary text, which has to match
 \dd{/[a-zA-Z0-9]+/} regular expression, to the end of the prefix and calculates
 \href{https://en.wikipedia.org/wiki/SHA-2}{SHA-256 hash}
 of the text in the hexadecimal format. For example, this would be the prefix
-with the attached \dd{117b1f} suffix:
+with the attached \dd{16bda66} suffix:
 
 \begin{minted}{text}
-2018-05-17T03:50:59Z b2.zold.io 4096 THdonv1E@0000000000000000 117b1f
+2018-05-17T03:50:59Z b2.zold.io 4096 THdonv1E@abcdabcdabcdabcd 16bda66
 \end{minted}
 
-The hash of this text will be:
+The hash of this text will be (pay attention to the trailing zeroes):
 
 \begin{minted}{text}
-670baa704726fe2c837c5ca764202adca5ab12c9b90c94d9fb1b8d629000000
+5fa0681f220a2779b03b46456a19b38c0b635c1573dc01401dafee510000000
 \end{minted}
 
 The node attempts to try different sufficies until one of them produces
 a hash that ends with a few tailing zeroes. The one above ends
-with six zeroes
-(it took three minutes to find it on 2.3GHz Intel Core i7):
+with six zeroes.
 
 When the first suffix is found, the score is 1. Then, to
 increase the score by one, the next suffix has to be found, which
@@ -177,31 +289,34 @@ can be added to the first 64 characters of the previous hash
 in order to obtain a new hash with trailing zeros, for example:
 
 \begin{minted}{text}
-2018-05-17T03:50:59Z b2.zold.io 4096 THdonv1E@0000000000000000 117b1f 1546e35
+2018-05-17T03:50:59Z b2.zold.io 4096 THdonv1E@abcdabcdabcdabcd 16bda66 13d284b
 \end{minted}
 
 Produces:
 
 \begin{minted}{text}
-99dcd18e4bd03004e1205437866b5b68035cc8985240ae52cbd37640a000000
+ce420bfdd2f6530db795e7ff4aa508bb0092735dd63d209da218cb78b000000
 \end{minted}
 
 And so on.
 
 The score is valid only when the starting time point is earlier than
-the current time, but not earlier than 24 hours ago. The strength of the score
+the current time, but not earlier than 24 hours ago. The \emph{strength} of the score
 is the amount of the trailing zeros in the hash. In the example above the
-strength is six.
+strength is six. The larger the strength, the more CPU power it takes to earn
+the score. All nodes in the network must have the same strength of their scores.
+
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \section{Wallets}
 
-There is no central ledger in Zold, like many other digital currencies.
+There is no central ledger in Zold, like in many other digital currencies.
 Instead, each user has their own \emph{wallets} (any number of them) with their own ledgers inside.
 Each wallet is an ASCII-text file with the name equal to the wallet ID.
-For example, the wallet in the file \dd{12345678abcdef} may include:
+For example, the wallet in the file \dd{12345678abcdef} may include
+the following text:
 
 \begin{minted}{text}
 zold
@@ -209,10 +324,10 @@ zold
 12345678abcdef
 AAAAB3NzaC1yc2EAAAADAQABAAABAQCuLuVr4Tl2sXoN5Zb7b6SKMPrVjLxb...
 
-003a;2017-07-19T21:24:51Z;ffffffff9c0ccccd;Ui0wpLu7;98bb82c81735c4ee;For services;SKMPrVj...
-003b;2017-07-19T21:25:07Z;ffffffffffa72367;xksQuJa9;98bb82c81735c4ee;For food;QCuLuVr4...
-0f34;2017-07-19T21:29:11Z;0000000000647388;kkIZo09s;18bb82dd1735b6e9;-;
-003c;2017-07-19T22:18:43Z;ffffffffff884733;pplIe28s;38ab8fc8e735c4fc;For programming;2sXoN5...
+003a;2017-07-19T21:24:51Z; ffffffff9c0ccccd; Ui0wpLu7; 98bb82c81735c4ee; For services;SKMPrVj...
+003b;2017-07-19T21:25:07Z; ffffffffffa72367; xksQuJa9; 98bb82c81735c4ee; For food;QCuLuVr4...
+0f34;2017-07-19T21:29:11Z; 0000000000647388; kkIZo09s; 18bb82dd1735b6e9; -;
+003c;2017-07-19T22:18:43Z; ffffffffff884733; pplIe28s; 38ab8fc8e735c4fc; For programming;2sXoN5...
 \end{minted}
 
 Lines are separated by either CR or CRLF.
@@ -221,7 +336,7 @@ The header includes four lines:
 
 \begin{enumerate}
   \item Network name, \dd{[a-z]\{4,16\}};
-  \item Software version, \dd{[0-9]+(\.[0-9]+)\{1,2\}} (\href{https://semver.org/}{semantic versioning});
+  \item Software version, \dd{[0-9]+(\\.[0-9]+)\{1,2\}} (\href{https://semver.org/}{semantic versioning});
   \item Wallet ID, a 64-bit unsigned integer in hexadecimal format;
   \item Public \href{https://en.wikipedia.org/wiki/RSA_(cryptosystem)}{RSA}
     key of the wallet owner, in \href{https://en.wikipedia.org/wiki/Base64}{Base64}.
@@ -231,34 +346,30 @@ The ledger includes transactions, one per line. Each transaction line
 contains fields separated by a semi-colon:
 
 \begin{enumerate}
-  \item Transaction ID, an unsigned 16-bit integer, 4-symbols hex;
-  \item Date and time, in \href{https://en.wikipedia.org/wiki/ISO_8601}{ISO 8601} format, 20 symbols;
-  \item Amount, a signed 64-bit integer, 16-symbols hex;
-  \item Payment prefix, 8-32 symbols;
-  \item Wallet ID of the beneficiary, 16-symbols hex;
-  \item Details, matching \dd{/[a-zA-Z0-9 -.]\{1,128\}/};
-  \item \href{https://en.wikipedia.org/wiki/RSA_(cryptosystem)}{RSA} signature,
+  \item \dd{id}: Transaction ID, an unsigned 16-bit integer, 4-symbols hex;
+  \item \dd{time}: date and time, in \href{https://en.wikipedia.org/wiki/ISO_8601}{ISO 8601} format, 20 symbols;
+  \item \dd{amount}: Zents, a signed 64-bit integer, 16-symbols hex;
+  \item \dd{prefix}: Payment prefix, 8-32 symbols;
+  \item \dd{bnf}: Wallet ID of the beneficiary, 16-symbols hex;
+  \item \dd{details}: Arbitrary text, matching \dd{/[a-zA-Z0-9 -.]\{1,512\}/};
+  \item \dd{signature}: \href{https://en.wikipedia.org/wiki/RSA_(cryptosystem)}{RSA} signature,
     684 symbols in \href{https://en.wikipedia.org/wiki/Base64}{Base64}.
 \end{enumerate}
 
 Transactions with positive amount don't have signatures.
 Their IDs point to ID fields of corresponding beneficiaries' wallets.
 
-The combination ``ID'' + ``Beneficiary'' is unique in the entire wallet.
+The \dd{prefix} is a piece of text randomly selected from the RSA key
+of the beneficiary wallet. It is used for security reasons, in order
+to make impossible ``wallet masquerading'' (pushing a new wallet with the
+same ID, but a different key).
+
+The combination \dd{id}+\dd{bnf} must be unique in the entire wallet.
 
 The \href{https://en.wikipedia.org/wiki/RSA_(cryptosystem)}{RSA}
 signature is calculated using the private key of the
 wallet and the following fields of transaction, separated by spaces:
-
-\begin{enumerate}
-  \item Wallet ID;
-  \item Transaction ID, an unsigned 16-bit integer;
-  \item Date and time, in ISO 8601 format;
-  \item Amount, a signed 64-bit integer;
-  \item Payment prefix;
-  \item Wallet ID of the beneficiary;
-  \item Details, matching \dd{/[a-zA-Z0-9 -.]{1,128}/}.
-\end{enumerate}
+\dd{bnf}, \dd{id}, \dd{time}, \dd{amount}, \dd{prefix}, \dd{bnf}, \dd{details}.
 
 For example, this text may be used as a signing input:
 
@@ -266,21 +377,22 @@ For example, this text may be used as a signing input:
 12345678abcdef 003a 2017-07-19T21:24:51Z ffffffff9c0ccccd Ui0wpLu7 98bb82c81735c4ee For services
 \end{minted}
 
-Each transaction takes 900 symbols at most.
-The maximum amount of transactions in one wallet is 65536.
-Thus, a single wallet may be as big as a 59Mb text file, at most.
+Each transaction takes 1284 symbols at most.
+
+The order of transactions is not important, as long as their final balance is positive.
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \section{Mining Formula}
 
-The only way to get ZLD is to receive it from the \emph{root} wallet \dd{0000000000000000}.
+The only way to get ZLD is to receive it from the \emph{root} wallet
+with a system pre-defined ID \dd{0000000000000000}.
 This wallet is the only one that may have a negative ballance.
 However, to prevent an uncontrolled emission of ZLD, the balance
 of this wallet must satisfy the formula:
 
-$$x = \frac{2048}{h};\quad z = 2^{63 - x}.$$
+$$t = \frac{h}{24 \times 1024}; \quad z = 2^{63} \times (1 - 2^{-t}).$$
 
 Here $h$ is the age of the root wallet in hours and $z$ is the maximum
 amount of zents it can issue at that moment. The first
@@ -290,29 +402,15 @@ six years will look like this:
 \hline
 Year & ZLD & Share \\
 \hline
-1st & 32m & 0.01\% \\
-2nd & 4b & 0.77\% \\
-3rd & 21b & 4\%\\
-4th & 48b & 9\% \\
-5th & 78b & 14\% \\
-6th & 108b & 20\% \\
+1st & 470m & 22\% \\
+2nd & 837m & 39\% \\
+3rd & 1.1b & 52\%\\
+4th & 1.3b & 63\% \\
+5th & 1.5b & 71\% \\
+6th & 1.7b & 77\% \\
 \hline
 \end{tabular}\end{center}
 
-On a large perspective of 25 years total emission of ZLD will look
-like this:
-
-\vspace{\parskip}\begin{center}\begin{tikzpicture}
-\begin{axis}[
-  axis lines=middle,
-  width=12cm,height=5cm,
-  xlabel={Age, in years},
-  ylabel={Billions of ZLD},
-]
-\addplot[domain=-0:25, samples=25]{2^(39-2048/(x*24*365)) / 1000000000};
-\end{axis}
-\end{tikzpicture}\end{center}
-
 The limitation is hardwired in Zold software and can't be eliminated.
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
@@ -323,10 +421,8 @@ The limitation is hardwired in Zold software and can't be eliminated.
 Each wallet must have to pay \emph{taxes} in order to be promoted by nodes.
 The maximum amount of tax debt a node can tolerate is 1 ZLD. This means
 that if the debt is smaller, all nodes must promote the wallet to their
-remote nodes. If the debt is bigger, a node will accept the wallet but won't
-promote it further, which will seriously decrease wallet's visibility in
-the network---only a limited amount of nodes will see it, unless the owner
-manually pushes it to many nodes, which is an expensive operation.
+remote nodes. If the debt is bigger, a node will reject the wallet,
+which will make it impossible to make any new payments from it.
 
 The amount of taxes to be paid is calculated by the following formula:
 
@@ -337,19 +433,26 @@ which is calculated as the difference in hours between the current time
 and the time of the oldest transaction in the wallet.
 $T$ is the total number of transactions in the wallet.
 $F$ is the fee per transaction/hour, which is equal to 7.48 zents
-(a one-year-old wallet with 4096 transactions inside must pay approximately 16 ZLD taxes annually).
+(a one-year-old wallet with 4096 transactions must pay approximately 16 ZLD taxes annually).
 
 In order to pay taxes the owner of the wallet has to select any remote
 node from the network, which has a score of 16 or more. Then, it has to
-take the invoice from the score and send the payment of 1 ZLD or less
-to that node. The score has to be placed into the details of the transaction,
-prefixed by \dd{TAXES }. All tax payments inside a wallet must
-have unique scores.
+take the invoice from the score, request the node to lock the score
+for a minute, and send the payment of 1 ZLD or less
+to that node. The score with exactly 16 suffixes
+has to be placed into the details of the transaction,
+prefixed by \dd{TAXES }.
+
+The most active remote node will be selected as tax receiver.
+It's up to the payer which node to select.
+
+All tax payments inside a wallet must have unique scores.
+Duplicate tax payments are ignored.
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-\section{Fetch, Merge, and Propagate}
+\section{Remote Nodes}
 
 Each node maintains a list of \emph{remote nodes} (their host names and TCP port numbers),
 their scores and their availability information. When the node is just installed,
@@ -359,6 +462,22 @@ to high-score nodes and the nodes with the highest availability.
 Moreover, the node adds new elements to the list retrieving them from all
 available remote nodes.
 
+The built-in mechanism pays attention to the following factors of
+remote node \emph{quality} (in order of importance):
+
+\begin{enumerate}
+  \item Visibility: the payer has to know the node,
+  \item Availability: the amount of errors seen recently,
+  \item Knowledgeability: the amount of nodes this node is aware of,
+  \item Activity: the frequency of push requests the node originates,
+  \item Score: the one reported during the most recent handshake.
+\end{enumerate}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\section{Fetch, Merge, and Propagate}
+
 First, to see a wallet, it has to be \emph{fetched} from a number of remote
 nodes. The nodes may provide different versions of the same wallet, either
 because some data is corrupted or because modifications were made to the same
@@ -417,11 +536,11 @@ if it doesn't yet exist there.
 \section{Pay and Push}
 
 To send money from one wallet to another, the owner of the sending wallet
-has to add a negative transaction to it, signing it with the private RSA key.
+has to add a negative transaction to it and sign it with the private RSA key.
 
 At any moment of time any node may decide to push a wallet to another node.
-The accepts it, merges with the local version, and keeps locally. Then, it
-\emph{promotes} the wallet to all known remote nodes.
+The receiving node accepts it, merges with the local version, and keeps locally.
+Then, it \emph{promotes} the wallet to all known remote nodes.
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
@@ -433,7 +552,9 @@ Each response has \dd{Content-Type},
 \dd{Content-Length}, and \dd{X-Zold-Version}
 HTTP headers.
 
-\dd{GET /} is a home page of a node that returns JSON response with the
+\dd{GET /} is a home page of a node that returns
+JSON/\href{https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.1}{200}
+response with the
 information about the node, for example (other details may be added in
 further versions):
 
@@ -451,7 +572,8 @@ further versions):
 }
 \end{minted}
 
-\dd{GET /remotes} returns the list of remote nodes known by the node, in JSON:
+\dd{GET /remotes} returns the list of remote nodes known by the node,
+in JSON/\href{https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.1}{200}:
 
 \begin{minted}{json}
 {
@@ -462,7 +584,8 @@ further versions):
   ]
 }\end{minted}
 
-\dd{GET /wallet/<ID>} returns the content of the wallet:
+\dd{GET /wallet/<ID>} returns the content of the wallet, in
+JSON/\href{https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.1}{200}:
 
 \begin{minted}{json}
 {
@@ -474,7 +597,7 @@ If the wallet is not found, a
 \href{https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.5}{404}
 HTTP response is returned.
 
-If the client provided the MD5 hash of the wallet content in the
+If the client provided the pre-calculated MD5 hash of the wallet content in the
 \href{https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.26}{\dd{If-None-Match}}
 HTTP header and it matches with the hash of the
 content the node contains, a
@@ -516,20 +639,26 @@ on the wallets coming in? If the node doesn't accept a push request,
 its availability rating decreases and other nodes will stop paying
 taxes to it.
 
-\subsection{To Promote Other Nodes}
+\subsection{To Advertise Other Nodes}
 
-What is the incentive to promote other remote nodes via the \dd{/remotes} RESTful
+What is the incentive to advertise other remote nodes via the \dd{/remotes} RESTful
 entry point and why can't a node always return an empty list, expecting its clients
 to always pay taxes to it? The software automatically prioritizes remote
 nodes by the amount of remote nodes it promotes. The longer the list a node
 returns, the higher its chance to be at the top of the list.
 
-\colorbox{yellow}{We need more here}
+\subsection{To Promote Wallets}
+
+What is the incentive to promote wallets to remote nodes, spending network
+traffic for this operation? Each node ranks its remote nodes also by the
+amount of push requests they send. Thus, in order to stay on top of the lists
+each node is interested to push wallets further.
+
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-\section{Threats}
+\section{Threats \& Responses}
 
 It is obvious that a distributed system that consists of anonymous nodes
 even theorecially can't be 100\% safe, reliable, secure and trustworthy.
@@ -538,7 +667,7 @@ to mitigate all critical threats and make the system ``reliable enough.''
 This Section summarizes the most import of those threads and explains
 how Zold responds to them.
 
-\subsection{Double Spending}
+\subsection{Double Spending Attack}
 
 It is possible to submit the same spending transaction to the same wallet
 and then push it to two different nodes in different parts of the network.
@@ -552,6 +681,28 @@ one, and one of the transactions will be rejected from the wallet, after
 a number of merge operations in all nodes of the network. The receiver of the
 money must be careful and always to the full fetch (from as many
 
-\colorbox{yellow}{We need more here}
+\subsection{51\% Attack}
+
+A group of nodes can combine their CPU power in order to win the consensus
+algorithm and add fraudulent incoming transactions to a wallet.
+The fetching node will trust the wallet ``as is'' and will think that the
+balance of the wallet is larger than it actually is.
+
+This may happen, but a fetching node may always re-validate the entire wallet,
+by checking RSA signatures of all transactions. This will take some time, but will
+provide an extra guarantee to the client.
+
+\subsection{Fraudulent Tax Refunds}
+
+Some nodes may resell their scores to their affiliated tax payers, and they
+refund them some amount of taxes back. This will be profitable both for
+the tax payers, since they will pay less taxes, and for the node owners,
+since they will receive the payments anyway.
+
+This scenario is indeed possible, but it is assumed that since tax payments are
+supposed to be made in small increments and automatically, the majority of
+clients won't be interested in this fraudulent scheme.
+
+\printbibliography%
 
 \end{document}