zold 0.10.17 → 0.10.18

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: f82eb3e8bbf86a83ea78315d7ecb2018ef1f6fcb
-  data.tar.gz: 9fc982bf05be569cb2bf9d1fe821fb6fcb9d1f53
+  metadata.gz: 38e652467a444ab842b0541b9ffd7bb387e90325
+  data.tar.gz: 5386183382f20e4cb78e3b2dacd4f83ba02ef896
 SHA512:
-  metadata.gz: 0df44ded0be61884ca4ceb84cc844bc20867abc8cc96a23ea510285ef6daabf371c1660423bcdd696ddbced6e0886318ad7b987f920703f032c8211b360c8fbe
-  data.tar.gz: d89ea78fff3c9e9f7c8434b93b29bf6532d224509f259db03212aafbbd0440ab52fca845a27c25a4b801054954cde3826bc1a6b2c66004b6a4835b706586ee32
+  metadata.gz: d7eb3aa339296a9d9b21891d7dbba0eb1d8479fcbe52724bc76d189bbf262095a90bbc8939a58ca984559c3f55d3c8d5fdcfbecd1ca27d5124ca9e0126ddc476
+  data.tar.gz: 9affbc7d7f5c4a04a92fc7d27287d802e1dd27d543ce0f0575d78acba9779defaddac4fdf5c7601c4df179a333ee15335d4b5e70619e2c03e673c06f99aa8915

data/README.md

@@ -1,34 +1,34 @@
 <img src="http://www.zold.io/logo.svg" width="92px" height="92px"/>
 
 [![EO principles respected here](http://www.elegantobjects.org/badge.svg)](http://www.elegantobjects.org)
-[![Managed by Zerocracy](https://www.0crat.com/badge/C91QJT4CF.svg)](https://www.0crat.com/p/C91QJT4CF)
-[![DevOps By Rultor.com](http://www.rultor.com/b/yegor256/Zold)](http://www.rultor.com/p/yegor256/Zold)
+[![Managed by Zerocracy](https://www.0crat.com/badge/CAZPZR9FS.svg)](https://www.0crat.com/p/CAZPZR9FS)
+[![DevOps By Rultor.com](http://www.rultor.com/b/yegor256/zold)](http://www.rultor.com/p/yegor256/zold)
 [![We recommend RubyMine](http://www.elegantobjects.org/rubymine.svg)](https://www.jetbrains.com/ruby/)
 
-[![Build Status](https://travis-ci.org/yegor256/zold.svg)](https://travis-ci.org/yegor256/zold)
-[![Build status](https://ci.appveyor.com/api/projects/status/ypctxm5ohrtp2kr4?svg=true)](https://ci.appveyor.com/project/yegor256/zold)
-[![PDD status](http://www.0pdd.com/svg?name=yegor256/zold)](http://www.0pdd.com/p?name=yegor256/zold)
+[![Build Status](https://travis-ci.org/zold-io/zold.svg)](https://travis-ci.org/zold-io/zold)
+[![Build status](https://ci.appveyor.com/api/projects/status/ypctxm5ohrtp2kr4?svg=true)](https://ci.appveyor.com/project/zold-io/zold)
+[![PDD status](http://www.0pdd.com/svg?name=zold-io/zold)](http://www.0pdd.com/p?name=zold-io/zold)
 [![Gem Version](https://badge.fury.io/rb/zold.svg)](http://badge.fury.io/rb/zold)
-[![Test Coverage](https://img.shields.io/codecov/c/github/yegor256/zold.svg)](https://codecov.io/github/yegor256/zold?branch=master)
+[![Test Coverage](https://img.shields.io/codecov/c/github/zold-io/zold.svg)](https://codecov.io/github/zold-io/zold?branch=master)
 
-[![Dependency Status](https://gemnasium.com/yegor256/zold.svg)](https://gemnasium.com/yegor256/zold)
-[![Maintainability](https://api.codeclimate.com/v1/badges/7489c1d2bacde40ffc09/maintainability)](https://codeclimate.com/github/yegor256/zold/maintainability)
+[![Dependency Status](https://gemnasium.com/zold-io/zold.svg)](https://gemnasium.com/zold-io/zold)
+[![Maintainability](https://api.codeclimate.com/v1/badges/7489c1d2bacde40ffc09/maintainability)](https://codeclimate.com/github/zold-io/zold/maintainability)
 
 **NOTICE**: It's an experiment and a very early draft! Please, feel free to
 submit your ideas and/or pull requests.
 
-Here is the [White Paper](https://github.com/yegor256/zold/raw/master/wp/wp.pdf).
+Here is the [White Paper](https://github.com/zold-io/papers/raw/master/wp.pdf).
 
 Join our [Telegram group](https://t.me/zold_io) to discuss it all live.
 
-The license is [MIT](https://github.com/yegor256/zold/blob/master/LICENSE.txt).
+The license is [MIT](https://github.com/zold-io/zold/blob/master/LICENSE.txt).
 
 ## How to Use
 
 First, install [Ruby 2.3+](https://www.ruby-lang.org/en/documentation/installation/),
 [Rubygems](https://rubygems.org/pages/download), and
 the [gem](https://rubygems.org/gems/zold).
-Here is [how](https://github.com/yegor256/zold/blob/master/INSTALL.md).
+Here is [how](https://github.com/zold-io/zold/blob/master/INSTALL.md).
 
 To make sure it's installed, try:
 
@@ -149,7 +149,7 @@ $ bundle update
 $ rake
 ```
 
-The build has to be clean. If it's not, [submit an issue](https://github.com/yegor256/zold/issues).
+The build has to be clean. If it's not, [submit an issue](https://github.com/zold-io/zold/issues).
 
 Then, make your changes, make sure the build is still clean,
 and [submit a pull request](https://www.yegor256.com/2014/04/15/github-guidelines.html).

data/lib/zold/commands/invoice.rb

@@ -50,7 +50,7 @@ Available options:"
       raise 'Receiver wallet ID is required' if mine[0].nil?
       id = Zold::Id.new(mine[0])
       wallet = @wallets.find(id)
-      raise "Wallet #{id} doesn\'t exist in #{@wallets}, do 'fetch' first" unless wallet.exists?
+      raise "Wallet #{id} doesn\'t exist in #{@wallets}, do 'pull' first" unless wallet.exists?
       invoice(wallet, opts)
     end
 

data/lib/zold/commands/remote.rb

@@ -72,6 +72,7 @@ Available options:"
       end
       mine = Args.new(opts, @log).take || return
       command = mine[0]
+      raise "A command is required, try 'zold remote --help'" unless command
       case command
       when 'show'
         show

data/lib/zold/node/front.rb

@@ -76,6 +76,8 @@ module Zold
         Remote.new(remotes: settings.remotes, log: settings.log).run(
           ['remote', 'add', s.host, s.port.to_s, '--force']
         )
+      else
+        settings.log.debug("#{request.url}: the score is too weak: #{s}")
       end
     end
 

data/lib/zold/version.rb

@@ -23,5 +23,5 @@
 # Copyright:: Copyright (c) 2018 Yegor Bugayenko
 # License:: MIT
 module Zold
-  VERSION = '0.10.17'.freeze
+  VERSION = '0.10.18'.freeze
 end

data/zold.gemspec

@@ -36,7 +36,7 @@ Gem::Specification.new do |s|
   s.description = 'Non-blockchain cryptocurrency'
   s.authors = ['Yegor Bugayenko']
   s.email = 'yegor256@gmail.com'
-  s.homepage = 'http://github.com/yegor256/zold'
+  s.homepage = 'http://github.com/zold-io/zold'
   s.files = `git ls-files`.split($RS)
   s.executables = s.files.grep(%r{^bin/}) { |f| File.basename(f) }
   s.test_files = s.files.grep(%r{^(test|spec|features|wp)/})

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: zold
 version: !ruby/object:Gem::Version
-  version: 0.10.17
+  version: 0.10.18
 platform: ruby
 authors:
 - Yegor Bugayenko
@@ -371,14 +371,8 @@ files:
 - test/test_wallet.rb
 - test/test_wallets.rb
 - test/test_zold.rb
-- wp/.gitignore
-- wp/Makefile
-- wp/logo.pdf
-- wp/main.bib
-- wp/wp.pdf
-- wp/wp.tex
 - zold.gemspec
-homepage: http://github.com/yegor256/zold
+homepage: http://github.com/zold-io/zold
 licenses:
 - MIT
 metadata: {}
@@ -446,9 +440,3 @@ test_files:
 - test/test_wallet.rb
 - test/test_wallets.rb
 - test/test_zold.rb
-- wp/.gitignore
-- wp/Makefile
-- wp/logo.pdf
-- wp/main.bib
-- wp/wp.pdf
-- wp/wp.tex

data/wp/.gitignore

@@ -1,8 +0,0 @@
-_minted-wp
-wp.aux
-wp.bcf
-wp.bbl
-wp.blg
-wp.log
-wp.out
-wp.run.xml

data/wp/Makefile

@@ -1,13 +0,0 @@
-OPTS=-shell-escape -halt-on-error -interaction=errorstopmode -output-directory=.
-
-wp.pdf: wp.tex
-	pdflatex ${OPTS} wp.tex > /dev/null
-	biber wp > /dev/null
-	pdflatex ${OPTS} wp.tex > /dev/null
-	grep 'LaTeX Warning' wp.log ; if [ $$? -eq 0 ]; then cat wp.log; exit -1; fi
-	grep 'Overfull ' wp.log ; if [ $$? -eq 0 ]; then cat wp.log; exit -1; fi
-	grep 'Underfull ' wp.log ; if [ $$? -eq 0 ]; then cat wp.log; exit -1; fi
-
-clean:
-	rm -rf wp.log wp.pdf wp.out wp.aux
-

data/wp/main.bib

@@ -1,99 +0,0 @@
-@article{nakamoto2008,
-  title={Bitcoin: A Peer-to-peer Electronic Cash System},
-  author={Nakamoto, Satoshi},
-  year={2008}
-}
-
-@article{buterin2013,
-  author={Vitalik Buterin},
-  title={Ethereum: A Next-Generation Smart Contract and Decentralized Application Platform},
-  year={2013},
-  url={https://github.com/ethereum/wiki/wiki/White-Paper}
-}
-
-@article{popov2017,
-  title={The Tangle},
-  author={Serguei Popov},
-  year={2017},
-  url={https://iotatoken.com/IOTA_Whitepaper.pdf}
-}
-
-@inproceedings{kaskaloglu2014,
-  title={Near Zero Bitcoin Transaction Fees Cannot Last Forever},
-  author={Kaskaloglu, Kerem},
-  booktitle={The International Conference on Digital Security and Forensics},
-  pages={91--99},
-  year={2014},
-  organization={The Society of Digital Information and Wireless Communication}
-}
-
-@article{van2014,
-  title={Why Bitcoin Has Value},
-  author={Van Alstyne, Marshall},
-  journal={Communications of the ACM},
-  volume={57},
-  number={5},
-  pages={30--32},
-  year={2014},
-  publisher={ACM}
-}
-
-@article{andreessen2014,
-  title={Why Bitcoin Matters},
-  author={Andreessen, Marc},
-  journal={New York Times},
-  volume={21},
-  year={2014}
-}
-
-@article{pilkington2016,
-  title={Blockchain Technology: Principles and Applications},
-  author={Pilkington, Marc},
-  journal={Research Handbook on Digital Transformations},
-  pages={225},
-  year={2016},
-  publisher={Edward Elgar Publishing}
-}
-
-@inproceedings{karame2012,
-  title={Double-spending Fast Payments in Bitcoin},
-  author={Karame, Ghassan O. and Androulaki, Elli and Capkun, Srdjan},
-  booktitle={Proceedings of the 2012 ACM conference on Computer and communications security},
-  pages={906--917},
-  year={2012},
-  organization={ACM}
-}
-
-@inproceedings{everaere2010,
-  title={Double Spending Protection for E-cash Based on Risk Management},
-  author={Everaere, Patricia and Simplot-Ryl, Isabelle and Traor{\'e}, Issa},
-  booktitle={International Conference on Information Security},
-  pages={394--408},
-  year={2010},
-  organization={Springer}
-}
-
-@techreport{boyen2016,
-  title={Blockchain-free Cryptocurrencies: A Framework for Truly Decentralised Fast Transactions},
-  author={Boyen, Xavier and Carr, Christopher and Haines, Thomas},
-  year={2016},
-  institution={Cryptology ePrint Archive, Report 2016/871}
-}
-
-@inproceedings{moser2015,
-  title={Trends, Tips, Tolls: A Longitudinal Study of Bitcoin Transaction Fees},
-  author={M{\"o}ser, Malte and B{\"o}hme, Rainer},
-  booktitle={International Conference on Financial Cryptography and Data Security},
-  pages={19--33},
-  year={2015},
-  organization={Springer}
-}
-
-@article{kiayias2015,
-  title={Speed-Security Tradeoffs in Blockchain Protocols},
-  author={Kiayias, Aggelos and Panagiotakos, Giorgos},
-  journal={IACR Cryptology ePrint Archive},
-  volume={2015},
-  pages={1019},
-  year={2015}
-}

data/wp/wp.tex

@@ -1,731 +0,0 @@
-\documentclass[11pt,oneside]{article}
-\usepackage[utf8]{inputenc}
-\usepackage[american]{babel}
-\usepackage{bookmark}
-\usepackage{microtype}
-% \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}
-  \usemintedstyle{bw}
-  \BeforeBeginEnvironment{minted}{\vspace{6pt}\begin{mdframed}[topline=false,rightline=false,bottomline=false,linecolor=black,linewidth=2pt]}
-  \AfterEndEnvironment{minted}{\end{mdframed}}
-\usepackage{xcolor}
-\usepackage{graphicx}
-\pagecolor{black!3}
-\newcommand\dd[1]{\colorbox{gray!30}{\texttt{#1}}}
-\usepackage{hyperref}
-  \hypersetup{colorlinks=true,allcolors=blue!40!black}
-\setlength{\topskip}{6pt}
-\setlength{\parindent}{0pt} % indent first line
-\setlength{\parskip}{6pt} % before par
-
-\title{\includegraphics[scale=0.3]{logo.pdf}\\Zold: A Fast Cryptocurrency for Micro Payments}
-\author{Yegor Bugayenko\\\texttt{yegor256@gmail.com}}
-
-\begin{document}
-\raggedbottom
-
-\maketitle
-\begin{abstract}
-In the last few years digital currencies have 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
-dominating currencies like Bitcoin and Etherium. Despite its
-popularity, Blockchain is not the best possible solution for all scenarios.  One such example is
-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 wallet maintenance.
-\end{abstract}
-
-\section{Motivation}
-
-Bitcoin, the first decentralized digital currency, was released in January 2009~\parencite{nakamoto2008}.
-In the 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 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 Bitcoin was created, 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 to 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 by sending to an 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
-  dedicated hard drive space, the higher probability of mining
-  the next block and earning a reward.
-  ``Proof-of-Elapsed-Time'': one uses a 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 is also a decentralized digital currency that maintains its ledgers
-through 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 present in 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'' according to~\textcite{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
-with existing Blockchain-based digital currencies.
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-\section{Principles}
-
-\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.
-Section~\ref{sec:wallets} explains how it works.
-
-\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.
-Section~\ref{sec:score} describes the algorithm being used.
-
-\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, explained in Section~\ref{sec: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.
-Section~\ref{sec:taxes} provides more details.
-
-\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.
-Section~\ref{sec:remotes} explains how nodes communicate and rate each other.
-
-\textbf{Open Source}.
-Zold is a command line tool. Its entire code base is open
-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^{32}$ \emph{zents} (4,294,967,296).
-All amounts are stored as signed 64-bit integers.
-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.
-}
-
-\textbf{Hexspeak}.
-Wallet ID is a 16-digit hexadecimal number, which is not restricted by any formula.
-A user may make up any number, even using
-\href{https://en.wikipedia.org/wiki/Hexspeak}{Hexspeak}.
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-\section{Proof of Work}\label{sec:score}
-
-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}~\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,
-because it requires a lot of CPU power. It is assumed that at any moment
-of time the majority of nodes in the network invest their CPU power into
-calculating the nonces for the data that is not corrupted. If and when for any reason
-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~\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{score},
-which is as big as much CPU power the node has invested into its calculation.
-
-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:
-
-\begin{enumerate}
-\item The current timestamp in UTC, in \href{https://en.wikipedia.org/wiki/ISO_8601}{ISO 8601},
-\item The host name or IP address, e.g. \dd{b2.zold.io},
-\item The \href{https://en.wikipedia.org/wiki/Port_(computer_networking)}{TCP port} number,
-\item The invoice.
-\end{enumerate}
-
-For example, the prefix may look like this:
-
-\begin{minted}{text}
-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{16bda66} suffix:
-
-\begin{minted}{text}
-2018-05-17T03:50:59Z b2.zold.io 4096 THdonv1E@abcdabcdabcdabcd 16bda66
-\end{minted}
-
-The hash of this text will be (pay attention to the trailing zeroes):
-
-\begin{minted}{text}
-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.
-
-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
-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@abcdabcdabcdabcd 16bda66 13d284b
-\end{minted}
-
-Produces:
-
-\begin{minted}{text}
-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 \emph{strength} of the score
-is the amount of the trailing zeros in the hash. In the example above the
-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}\label{sec:wallets}
-
-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
-the following text:
-
-\begin{minted}{text}
-zold
-0.6.4
-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...
-\end{minted}
-
-Lines are separated by either CR or CRLF.
-There is a header and a ledger, separated by an empty line.
-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 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}.
-\end{enumerate}
-
-The ledger includes transactions, one per line. Each transaction line
-contains fields separated by a semi-colon:
-
-\begin{enumerate}
-  \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 \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:
-\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:
-
-\begin{minted}{text}
-12345678abcdef 003a 2017-07-19T21:24:51Z ffffffff9c0ccccd Ui0wpLu7 98bb82c81735c4ee For services
-\end{minted}
-
-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}\label{sec:formula}
-
-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:
-
-$$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
-six years will look like this:
-
-\vspace{\parskip}\begin{center}\begin{tabular}{lrr}
-\hline
-Year & ZLD & Share \\
-\hline
-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}
-
-The limitation is hardwired in Zold software and can't be eliminated.
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-\section{Taxes}\label{sec:taxes}
-
-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 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:
-
-$$X = A \times F \times T.$$
-
-$A$ is the total age of the wallet,
-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 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, 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{Remote Nodes}\label{sec:remotes}
-
-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,
-the list contains a limited amount of pre-defined addresses. The list is
-updated both by user request and automatically in order to give priority
-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
-wallet from different parts of the network. Each version retrieved from the
-network is stored in a local \emph{copy} and gets a score assigned to it.
-The score of the local copy is a summary of all scores of the nodes that
-provided that copy. Let's say, there are 17 nodes in the network and they
-provided three different copies of the wallet:
-
-\begin{minted}{text}
-copy-1: 78,090 bytes, 11 servers, 177 score
-copy-2: 56,113 bytes, 4 servers, 69 score
-copy-3: 97,132 bytes, 2 servers, 37 score
-\end{minted}
-
-The fetch operation ends at this point. The next step is to \emph{merge}
-all three copies into the local one, if it exists. The algorithm of merging
-is the following.
-
-First, the copy of the wallet we are merging into, is added to the list,
-with the score zero:
-
-\begin{minted}{text}
-copy-0: 55,991 bytes, 0 servers, 0 score
-copy-1: 78,090 bytes, 11 servers, 177 score
-copy-2: 56,113 bytes, 4 servers, 69 score
-copy-3: 97,132 bytes, 2 servers, 37 score
-\end{minted}
-
-Then, the copy with the highest score is assumed to be the correct one,
-which is the \dd{copy-1} in this example.
-
-Then, all other copies, in the order of their scores, are merged into the
-correct one, transaction by transaction, applied the following rules
-consequently:
-
-\begin{enumerate}
-\item If the transaction already exists, it's ignored;
-\item If the transaction is negative (spending money) and its ID is lower than
-the maximum ID in the ledger, it gets ignored as a fraudulent one (``double spending'');
-\item If the transaction makes the balance of the wallet negative, it is ignored;
-\item If the transaction is positive and its signature is not valid, it is ignored;
-\item If the transaction is negative and it's absent in the paying wallet
-(which is fetched and merged first), it's ignored;
-\item Otherwise, it gets added to the end of the ledger.
-\end{enumerate}
-
-When merge is done, the modifications get \emph{propagated} to other wallets
-available locally. Each transaction that has a negative amount is
-copied to the ledger of their receiving wallets (with a reversed sign),
-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 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 receiving node accepts it, merges with the local version, and keeps locally.
-Then, it \emph{promotes} the wallet to all known remote nodes.
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-\section{RESTful API}\label{sec:api}
-
-There is a limited set of RESTful API entry points in each node.
-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/\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):
-
-\begin{minted}{json}
-{
-  "version": "0.6.1",
-  "score": {
-    "value": 3,
-    "host": "b2.zold.io",
-    "port": 4096,
-    "invoice": "THdonv1E@0000000000000000",
-    "suffixes": [ "4f9c38", "49c074", "24829a" ],
-    "strength": 6
-  }
-}
-\end{minted}
-
-\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}
-{
-  "version": "0.6.1",
-  "all": [
-    { "host": "b2.zold.io", "port": 4096 },
-    { "host": "b1.zold.io", "port": 80 }
-  ]
-}\end{minted}
-
-\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}
-{
-  "version": "0.6.1",
-  "body": "..."
-}\end{minted}
-
-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 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
-\href{https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.5}{304} HTTP response is returned.
-
-\dd{PUT /wallet/<ID>} pushes the content of the wallet to the node. The
-node responds either with
-\href{https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.3}{202} (if accepted),
-\href{https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.1}{400} (if the data is corrupted),
-\href{https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.3}{402} (if taxes are not paid),
-or
-\href{https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.5}{304}
-(if the content is the same as the one the node already has).
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-\section{Incentives}\label{sec:incentives}
-
-It is obvious that anonymous users will participate in Zold and maintain
-their nodes only if they have enough financial motivation to do that. Simply
-put, their expenses must be lower than the income they are getting in
-form of taxes. This Section analyzes the most obvious questions users
-may have, regarding their motivation.
-
-\subsection{To Stay Online}
-
-What is the reason for a node to stay online and spend its CPU power
-and network traffic? Each node is insterested in doing that because it
-hopes that wallet owners will pay taxes to its invoices. The software
-automatically decides which node to pay taxes to and the selection is
-made by the availability criteria. The node which is the most available
-and visible will get the majority of tax payments.
-
-\subsection{To Accept Wallets}
-
-Why a node would accept push requests and spend its storage space
-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 Advertise Other Nodes}
-
-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.
-
-\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 and Responses}\label{sec:threats}
-
-It is obvious that a distributed system that consists of anonymous nodes
-even theorecially can't be 100\% safe, reliable, secure and trustworthy.
-Zold is not an exception. However, it's designed in an honest attempt
-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 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.
-They won't know about each other and will propagate those spending
-transactions to other wallets. Both two owners of those money receiving
-wallets will think that their money arrived, while only one of them is
-a legit receiver, the other transaction is fraudulent.
-
-This will happen, but very soon one part of the network will dominate the other
-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
-
-\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.
-
-\subsection{Loss of Wallet}
-
-A wallet is just a text file, which can easily be lost by it owner.
-
-This indeed is possible, but is not a risk at all, since all wallets are
-maintained by the network and anyone can easily pull any wallet back.
-The only sensitive part is the private key of the wallet. If that file
-is lost, the wallet can't pay anything anymore. This is the file all
-wallet owners must keep safe.
-
-\section{Conclusion}
-
-To be written...
-
-\printbibliography%
-
-\end{document}