First draft publish of general wp

Makefile

@@ -7,7 +7,7 @@ TMPFILES = *.aux *.log *.dvi *.bbl *.blg *.mtc* *.maf \
           $(shell find . -name "*.backup") \
           $(shell find . -name "auto")
 
-SRC=$(wildcard *.tex)
+SRC=$(wildcard bitshares-*.tex)
 BIBS=$(wildcard *.bib) $(wildcard *.bst)
 
 all: $(SRC:.tex=.pdf)
@@ -23,4 +23,4 @@ all: $(SRC:.tex=.pdf)
 	@bibtex $(shell basename $< .tex)
 
 clean:
-	@rm -rf $(TMPFILES) *.pdf
+	@rm -rf $(TMPFILES)

bitshares-consensus.tex

@@ -1,18 +1,10 @@
-\documentclass[conference,final,10pt,a4paper]{IEEEtran}
-
-\usepackage[latin1]{inputenc}
-\usepackage{amssymb,amssymb}
-\usepackage{algorithmic}
-
-\title{BitShares 2.0: Distributed Consensus}
+\documentclass{btswhitepaper}
+\title{BitShares 2.0: Consensus Mechanism}
 \input{AUTHORS}
-
-\IEEEoverridecommandlockouts
 \begin{document}
-\sloppy
 \maketitle
 
-\begin{abstract}
+\begin{abstract}%
 \end{abstract}
 \section    { Introduction                                   } \input { content/cons          } 
 \section    { Delegated Proof-of-Stake (DPOS)                } \input { content/cons-dpos     } 

bitshares-general.tex

@@ -1,5 +1,5 @@
 \documentclass{btswhitepaper}
-\title{BitShares 2.0: General Documentation}
+\title{BitShares 2.0: General Overview}
 \input{AUTHORS}
 \begin{document}
 \maketitle
@@ -20,7 +20,7 @@
 
 \section       { Introduction                      } \input { content/bts                 } 
 
-\section       { Crypto Token                      } \input { content/bts-token           } 
+\section       { Base Token                        } \input { content/bts-token           } 
 \subsection    { Distribution of BTS               } \input { content/bts-token-dist      } 
 \subsubsection { Bitshares PTS                     } \input { content/bts-token-dist-pts  } 
 \subsubsection { Bitshares AGS                     } \input { content/bts-token-dist-ags  } 
@@ -30,26 +30,29 @@
 \subsection    { BitShares Witnesses               } \input { content/bts-orga-witness    }
 \subsection    { BitShares Committee               } \input { content/bts-orga-committee  }
 \subsection    { BitShares Budget Items/Workers    } \input { content/bts-orga-budget     }
+\subsection    { Proxy Voting                      } \input { content/bts-orga-proxy      }
 
 \section       { BitShares: A profitable DAC       } \input { content/whatis-business     } 
 \subsection    { The Products                      } \input { content/bts-products        }
 \subsubsection { Price-stable SmartCoins           } \input { content/bts-products-mpa    }
 \subsubsection { Customizable Assets               } \input { content/bts-products-uia    }
 \subsubsection { Decentralized Exchange            } \input { content/bts-products-dex    }
 \subsubsection { Flexible Identity Management      } \input { content/bts-products-idm    }
-\subsubsection { International Payments            } \input { content/bts-products-pay    }
+%\subsubsection { International Payments            } \input { content/bts-products-pay    }
 
 \subsection    { Revenue and Expenses              } \input { content/bts-revenue-expense }
-\subsection    { Fee Schedule and Cash Flow        } \input { content/bts-fee             }
-\subsection    { Growth Considerations             } \input { content/whatis-growth       } 
+\subsection    { Memberships                       } \input { content/bts-memberships     }
+\subsection    { Referral Program                  } \input { content/whatis-growth       } 
 
 \section       { Architecture of BitShares         } \input { content/whatis-architecture } 
 \subsection    { Public Ledger                     } \input { content/spec-bc             } 
+\subsection    { Irreversibility of Transactions   } \input { content/spec-irreversible   }
 \subsection    { Low Latency Peer-to-Peer Network  } \input { content/spec-net            } 
 \subsection    { Distributed Consensus Mechanism   } \input { content/bts-consensus       } 
 \subsection    { Operations                        } \input { content/bts-ops             } 
 \subsection    { Transactions                      } \input { content/bts-txs             } 
-\subsection    { Objects                           } \input { content/bts-objs            } 
+\subsection    { Proposed Transactions             } \input { content/bts-txs-proposed    }
+%\subsection    { Objects                           } \input { content/bts-objs            } 
 
 \section       { Discussion                        } \input { content/bts-discussion      } 
 
@@ -61,31 +64,3 @@
 \bibliography{literature}
 %\nocite{*}
 \end{document}
-
-% Proxy voting:
-[00:21:02] bytemaster: Datasecuritynode asked a question. “When proxy voters are enabled, does the original account holder lose the complete ability to cast votes or do they know when the proxy cast their votes?
-[00:21:22] bytemaster: Well everyone knows when anything happens because the blockchain is public. At any time you can cast a vote to change your proxy. You can remove your proxy and cast votes, you can change proxies, you can do that at any time. But once you set a proxy if you’re not paying attention the proxy can change who they’re voting for without requiring you to do anything. And that’s a feature, that’s the intent of the proxy accounts.
-[00:21:58] bytemaster: So setting a proxy is not irrevocable. The other thing to keep in mind is that votes are only tallied once per day, which means if a proxy changes their vote and you don’t like how they changed it, you can change your proxy by the end of the day. So ideally, good proxiers would only change their vote at the beginning at the day to give everyone who’s using them an opportunity to review their changes by the end of the day before it has any impact on the consensus.
-[00:22:42] bytemaster: If you pick a proxy that changes their vote at the last second without an opportunity to review, they are probably a bad proxy for you to be using.
-[00:23:57] bytemaster: I think a lot of people have expressed that they would prefer to set the vote one time to someone they trust. And then let that person manage it. It’s more like an insurance policy. If it’s not going the direction you like, then you can pull it out and take action. Otherwise you leave it set on default and let some core group of individuals steer the ship.
-[00:24:20] bytemaster: That is centralizing in some respects, but it’s controlled centralization in the sense that nothing can happen too quickly and if you don’t like which way it’s going then you still have the ability to switch courses. I think that’s going to be the most practical way for things to go, which probably means a lot of people will choose to set me as the proxy vote and set some of the other core developers as their proxy vote if they think I’ve got to much power. And then just leave it like that, until a loss of confidence in the core developers to steer the ship, in which case you take ____ out and you vote directly.
-[00:25:08] bytemaster: So there’s some questions about proxy voting. Under BitShares 2.0 all balances are directly tied to your account unless you’re using blinded balances. The blinded balances, you do not vote. Because voting compromises privacy. So you can have your choice of either voting or being anonymous and blinded.
-[00:25:30] bytemaster: So when you vote, you specify ____ the list of accounts, a slate that you will be voting for. And when you set someone else as the proxy, your saying vote for me the same way they’re voting. This means that you’re going to use their list.
-
-% Decay voting
-[00:26:35] bytemaster: There’s another factor here that I’m glad you brought up. We need the ability for votes to decay. If you have not updated your vote or reaffirmed your vote, then you’re not continuing to assert your opinion and you’re kind of defaulting back to, well whatever the consensus is, you know whatever the active ___ is.
-[00:27:00] bytemaster: So if you want to have a say you’ve got to be active. You can’t be, Oh I’m going to vote for someone, and then disappear for a year. And then that person that you voted for does something terrible and you just don’t change your vote. You don’t review it. I look at it as kind of like, you don’t permanently cast a vote for the party you want. Each year you have to go out and cast your vote for governments. At companies every time there’s something that happens, you have to cast a vote.
-[00:27:37] bytemaster: So if you want to have a permanent vote, then nominate a proxy and then that proxy will be responsible for staying active and voting on a regular basis. But if you think about it, a vote at this point in time … these are good people, but as time progresses that past vote of confidence does not carry the same meaning. You can’t say this ____ good people for all time and so we need people to continually input into the system that this is currently someone who’s good. And if they don’t do that then their votes either decay or no longer count at all.
-[00:28:24] bytemaster: There’s another question that came up, “If you set a proxy who in turn sets another proxy”. You’re not going to follow the secondary proxy. The reason why we don’t allow you to do that is you could create cycles out of nondeterministic depth of the proxying of votes. So there is a limit on how indirect your voting can get.
-[00:29:00] bytemaster: Yes. Anything that can be parametrized will be parametrized.
-
-% More
-* irreversible blocks!
-
-% Worker
-for the worker properties you can choose:
-"type" can be "refund" (return your pay back to the pool to be used for future projects), "vesting" (pay that you pay yourself), or "burn" (destroys your pay thus reducing share supply, equivalent to share buy-back of a company stock)
-"pay_vesting_period_days" is the integer number of days you set for vesting.
-
-% proposed transactions
-to funds exchange accounts (gateway, merchants \ldots)

bitshares-growth.tex

@@ -1,15 +1,7 @@
-\documentclass[conference,final,10pt,a4paper]{IEEEtran}
-
-\usepackage[latin1]{inputenc}
-\usepackage{amssymb,amssymb}
-\usepackage{algorithmic}
-
+\documentclass{btswhitepaper}
 \title{BitShares 2.0: Growth Considerations}
 \input{AUTHORS}
-
-\IEEEoverridecommandlockouts
 \begin{document}
-\sloppy
 \maketitle
 
 \begin{abstract}
@@ -20,6 +12,7 @@
 \section  { Industrial Performance and Scalability } \input { content/grow-perf    } 
 \section  { Referral Rewards Program               } \input { content/grow-ref     } 
 \section  { Conclusion                             } \input { content/grow-conc    } 
+\nocite{*}
 \bibliographystyle{IEEEtran}
 \bibliography{literature}
 \end{document}

bitshares-history.tex

@@ -1,15 +1,7 @@
-\documentclass[conference,final,10pt,a4paper]{IEEEtran}
-
-\usepackage[latin1]{inputenc}
-\usepackage{amssymb,amssymb}
-\usepackage{algorithmic}
-
+\documentclass{btswhitepaper}
 \title{BitShares: Historical Overview}
 \input{AUTHORS}
-
-\IEEEoverridecommandlockouts
 \begin{document}
-\sloppy
 \maketitle
 
 \begin{abstract}
@@ -18,4 +10,8 @@
 How will BitShares 2.0 solve the problems with BitShares today?
 Lessons learned
 % https://bitsharestalk.org/index.php/topic,14019.0.html
+
+\nocite{*}
+\bibliographystyle{IEEEtran}
+\bibliography{literature}
 \end{document}

content/bts-discussion.tex

@@ -34,11 +34,21 @@
 by the blockchain. Where coins like Bitcoin dilute to pay for network security,
 BitShares takes these fees and directs them towards continual improvement of
 the network and community. This helps insure BitShares will stay competitive in
-its feature set. More details about the consensus scheme of BitShares can be
-found in a separated whitepaper~\cite{}.
+its feature set. More details about the consensus scheme of BitShares will be
+made available in a separated whitepaper.
 
 Recalling the initial distribution of BTS, it seem convincing to assume that
 most alternative distributions are way more unfair and some disproportionately
 favor their respective core developers. Since BitShares is a self-funded DAC,
 it can \emph{pay} for its future development autonomously by dilution, if
 shareholders reach an on-blockchain consensus by approval voting.
+
+Furthermore, it becomes clear from the descriptions that BitShares is governed
+by its shareholders and the committee whose members have shareholder approval.
+This allows for flexible adjustment of blockchain parameters, such as
+transaction fees, block interval, and more, as well as protocol upgrades to
+include new features.
+
+Since the BitShares is a self-funded blockchain, that can pay its workers by
+protocol, a healthy competition for new improvements, upgrades and additional
+features can be expected.

content/bts-memberships.tex

@@ -0,0 +1,16 @@
+Accounts in BitShares are separated into three groups. We decided to give users
+the option to upgrade their accounts into a VIP-like status if they desire and
+profit from reduced fees and additional features.
+
+A \emph{regular} account is a \emph{non-member}.
+
+\emph{Lifetime Members} get a percentage cashback on every transaction fee they
+pay and qualify to earn referral income (see below) from users they register
+with or refer to the network. A Lifetime membership is associated with a
+certain one-time fee that is defined by the committee and qualifies for reduced
+transaction fees.
+
+If a lifetime membership is too much you can still get the same cashback for
+the next year by becoming an annual subscriber for a smaller one-time fee which
+lasts for only one year and qualifies for reduced transactions fee during that
+time.

content/bts-orga-budget.tex

@@ -11,6 +11,14 @@
  \item an internet address.
 \end{inparaenum}
 has to be publish on the blockchain and approved by shareholders.
+A worker can also choose on of the following properties:
+\begin{itemize}
+ \item \emph{vesting}: pay to the worker's account
+ \item \emph{refund}: return the pay back to the reserve pool to be used for
+                      future projects
+ \item \emph{burn}: destroys the pay thus reducing share supply, equivalent to
+                    share buy-back of a company stock.
+\end{itemize}
 
 A blockchain parameter (defined by shareholders through the committee) defines
 the daily available budget. No more than that can be paid at any time to all so

content/bts-orga-proxy.tex

@@ -0,0 +1,15 @@
+\emph{Proxy Voting} denotes the process of handing out ones voting power to
+someone else. This process can be reverted to reclaim ones voting power.
+
+The motivation behind proxy voting is to reduce voting apathy and allow active
+shareholders to react more quickly to business and security concerns. That way,
+misbehaving witnesses can be fired more rapidly.
+
+That is centralizing in some respects, but it's controlled centralization in
+the sense that nothing can happen too quickly and if shareholders don't like
+which way it is going, still have the ability to switch courses. Compared to
+classical crypto currencies (e.g. Bitcoin), this process is somewhat similar to
+pooled mining with the exception that \emph{every} shareholder can participate
+and only \emph{voting power} is handed over. Furthermore, this allows for
+independent non-profit oriented decisions because there is no profit variance
+but purely political influence.