Huge update and Release of WP-1

AUTHORS.tex

@@ -1,16 +1,6 @@
 \author{
- Fabian~Schuh\\
- BitShares Europe, BitShares.eu\\
- BitShares Europe, BitShares.eu\\
- BitShares Europe, BitShares.eu\\
- Erlangen, Germany\\
- \texttt{[email protected]}\\[2ex]
- %%%%%%%
- Daniel~Larimer\\
- Cryptonomex, Cryptonomex.com\\
+ Fabian~Schuh, Daniel~Larimer\\
+ Cryptonomex, Cryptonomex.com\thanks{This work was supported by Cryptonomex and honorable members of the bitsharestalk.org community.}\\
  Blacksburg (VA), USA\\
- \texttt{[email protected]}%
- %%%%%%%
- \thanks{This work was supported by Cryptonomex and honorable members of the
-         bitsharestalk.org community.}
+ \texttt{\{\,fabian,\, dan\,\}@cryptonomex.com}
 }

bitshares-accounts.tex

@@ -0,0 +1,22 @@
+\documentclass{btswhitepaper}
+\title{BitShares 2.0: Identity Management}
+\input{AUTHORS}
+\begin{document}
+\maketitle
+
+\begin{abstract}%
+\end{abstract}
+
+\section    { Introduction                    } \input { content/idm-intro     } 
+
+\section    { Named Account                   } \input { content/bts-acc       } 
+\subsection { Transferability                 } \input { content/org-transfacc } 
+\subsection { Dynamic Permissions             } \input { content/org-dynacc    } 
+\subsection { Recurring \& Scheduled Payments } \input { content/org-recurr    } 
+\subsection { Costumer Privacy                } \input { content/bts-priv      } 
+
+\section    { Conclusion                      } \input { content/idm-conc      } 
+
+\bibliographystyle{IEEEtran}
+\bibliography{literature}
+\end{document}

bitshares-consensus.tex

@@ -27,3 +27,35 @@
 
 % Randomness of Witness Scheduling
 % https://bitsharestalk.org/index.php/topic,18126.msg231771.html#msg231771
+
+
+% https://bitsharestalk.org/index.php/topic,18613.msg239949.html#msg239949
+% Compromising one witness does not give you unlimited ability to perform a
+% double spend attack.   To perform the ``double-spend'' they would have to
+% broadcast the transaction 1 block before their turn, then skip the block that
+% included their first transaction and produce a block that contained an
+% alternative transaction\ldots *AND* have cooperation of the next witness which
+% would have to be in on it because that next witness would have seen the
+% original block/transaction first and would therefore ignore the bad witnesses'
+% block.
+% 
+% This means that you need at least 2 witnesses to attempt a double spend and you
+% could only do it any time those two witnesses were randomly selected to follow
+% one another.   
+% 
+% Lastly you could only perform the double spend attack as part of an anonymous
+% transaction (ie: paying someone who does not know your identity) and the
+% transaction and the other party would have to accept single confirmation
+% transactions and then take some kind of irreversible action.   As a result
+% meta-exchange, block trades, and exchanges would require several witnesses to
+% sign (up to 51% of the witnesses).    Because most witnesses will be publicly
+% known with real identities and reputations on the line, the risk of criminal
+% charges for a provable intentional double spend that is not rectified is enough
+% to prevent it from happening altogether.
+% 
+% The opportunity to execute large, anonymous transactions involving irreversible
+% actions in less than 10 seconds will be vanishingly small.   Once it was
+% detected everyone would be on notice to wait 10 seconds until 10 of 19
+% witnesses have signed and to vote out the attackers.    Therefore, you could
+% probably pull off the double spend ``ONCE'', the profit earned would be small
+% compared to the value of the income from the witnesses.

bitshares-financial-platform.tex

@@ -17,7 +17,7 @@
  % Several so called bitcoin 2.0 projects (among which are BitShares 1.0, NXT,
  % Counterparty, Ethereum, \dots) showed the feasibility (DEX).
  The aim of BitShares 2.0 is to evolve the term \emph{decentralized exchange}
- (DEX) and not only provide trading of assets but additionally offer classical
+ (DEX) and not only provide trading of assets but also offer classical
  financial instruments on the blockchain. Two of these instruments --- market
  pegged assets and user-issued assets --- are discussed here.
  % With price stable digital tokens such as bitUSD, a whole new set of
@@ -101,4 +101,3 @@
 % - review all occurrences of ``delegate''
 % - add QR code for more information?
 % - improve abstract and conclusions
-% - settlement & clearing

bitshares-general.tex

@@ -2,7 +2,6 @@
 \title{BitShares 2.0: General Documentation}
 \input{AUTHORS}
 \begin{document}
-\sloppy
 \maketitle
 
 \begin{abstract}%
@@ -21,11 +20,6 @@
 
 \section       { Introduction                      } \input { content/bts                 } 
 
-\section       { Architecture of BitShares         } \input { content/whatis-architecture } 
-\subsection    { Public Ledger                     } \input { content/spec-bc             } 
-\subsection    { Low Latency Peer-to-Peer Network  } \input { content/spec-net            } 
-\subsection    { Distributed Consensus Mechanism   } \input { content/bts-consensus       } 
-
 \section       { Crypto Token                      } \input { content/bts-token           } 
 \subsection    { Distribution of BTS               } \input { content/bts-token-dist      } 
 \subsubsection { Bitshares PTS                     } \input { content/bts-token-dist-pts  } 
@@ -38,26 +32,72 @@
 \subsection    { BitShares Budget Items            } \input { content/bts-orga-budget     }
 
 \section       { BitShares: A profitable DAC       } \input { content/whatis-business     } 
-\subsection    { The products                      } \input { content/bts-products        }
+\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    }
+
 \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       } 
 
-\section       { Technical Specifications          } \input { content/bts-specs           }
+\section       { Architecture of BitShares         } \input { content/whatis-architecture } 
+\subsection    { Public Ledger                     } \input { content/spec-bc             } 
+\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    { Named Account                     } \input { content/bts-acc             } 
-\subsubsection { Transferability                   } \input { content/org-transfacc       } 
-\subsubsection { Dynamic Permissions               } \input { content/org-dynacc          } 
-\subsubsection { Recurring \& Scheduled Payments   } \input { content/org-recurr          } 
-\subsubsection { Costumer Privacy                  } \input { content/bts-priv            } 
 
 \section       { Discussion                        } \input { content/bts-discussion      } 
 
 \section       { Conclusion                        } \input { content/bts-conc            } 
 
+% acknowledgment @ cass!!
+
 \bibliographystyle{IEEEtran}
 \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.
+
+
+
+
+

bitshares-marketengine.tex

@@ -0,0 +1,15 @@
+\documentclass{btswhitepaper}
+\title{BitShares 2.0: Market Engine}
+\input{AUTHORS}
+\begin{document}
+\maketitle
+
+\begin{abstract}%
+\end{abstract}
+
+\section       { Introduction                      } \input { content/bts                 } 
+
+\bibliographystyle{IEEEtran}
+\bibliography{literature}
+%\nocite{*}
+\end{document}

btswhitepaper.cls

@@ -82,8 +82,11 @@
  scale=1,angle=0,opacity=1,
  contents={%
  \begin{tikzpicture}[remember picture,overlay]
-  \path [fill=btsdark] (-0.5\paperwidth, 0.50\paperheight) 
+  %\path [fill=btsdark] (-0.5\paperwidth, 0.50\paperheight) 
+  %           rectangle ( 0.5\paperwidth, 0.25\paperheight);
+  \clip                (-0.5\paperwidth, 0.50\paperheight) 
              rectangle ( 0.5\paperwidth, 0.25\paperheight);
+  \node[anchor=north] at (0, 0.5\paperheight) {\includegraphics[width=\paperwidth]{figures/bg.jpg}};
  \end{tikzpicture}}
 }
 
@@ -95,17 +98,18 @@
  \let \footnote \thanks
  \begin{minipage}[t][.25\paperheight][t]{\textwidth}
   \begin{flushright}
-  \color{white}
-   {\LARGE\bfseries\textsc{\@title} \par}%
-    \vskip 3.5em%
+   \color{white}
+    {\LARGE\bfseries\textsc{\@title} \par}%
+    \vskip 5ex%
     {\normalsize
       \lineskip .5em%
-      \begin{minipage}{.3\linewidth}
-      \end{minipage}
-      {\color{white}\vrule width 2pt}\hskip.5em
-      \begin{minipage}{.3\linewidth}
+      \begin{minipage}{.5\linewidth}
+       \begin{flushright}
        \@author
+       \end{flushright}
       \end{minipage}
+      \hskip.5em
+      {\color{white}\vrule width 2pt}
     }%
   \end{flushright}
  \end{minipage}

content/bts-orga-budget.tex

@@ -0,0 +1,41 @@
+Thanks to the funds stored in the reserve pool, BitShares can offer to not only
+pay for its own development and protocol improvement but also support and
+encourage growth of an ecosystem.
+
+In order to be get paid by BitShares, a proposal containing
+\begin{inparaenum}[(a)]
+ \item the date of work begin,
+ \item the date of work end,
+ \item a daily pay (denoted in BTS),
+ \item the worker's name, and
+ \item an internet address.
+\end{inparaenum}
+has to be publish on the blockchain and approved by shareholders.
+
+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
+called \emph{workers} combined.
+
+The daily budget is distributed as illustrated in \cref{fig:workerpayalgo}: 
+\begin{inparaenum}[(1)]
+ \item The available budget is taken out of reserves pool.
+ \item The budget items are sorted according to their approval rate
+       ($v_\text{pro}-v_\text{con})$ in a descending order.
+ \item Starting at the worker with the highest approval rate, the requested
+       daily pay is payed until the daily budget is depleted.
+ \item The worker with the least approval rate that was paid may receive less
+       than the requested pay
+\end{inparaenum}
+
+\begin{figure}[!htp]
+ \centering
+  \includegraphics[width=\linewidth]{figures/worker-pay-algo.pdf}\vspace*{-2ex}
+ \caption{Illustration of budget item payments.}
+ \label{fig:workerpayalgo}
+\end{figure}
+Hence, in order to be successfully funded by the BitShares ecosystem, the
+shareholder approval for your budget item needs to be highly ranked.
+
+Since the payments for workers from the non-liquid reserve pool result in an
+increased supply of BTS, these payments are vesting over a period of time
+defined by shareholders.

content/bts-orga-committee.tex

@@ -0,0 +1,58 @@
+Since Bitcoin struggled to reach a consensus about the size of their blocks,
+the people in the cryptocurrency space realized that the governance of a DAC
+should not be ignored. Hence, BitShares offers a tools to reach on-chain
+consensus about business management decisions.
+
+The BitShares blockchain has a set of parameters available that are subject of
+shareholder approval. Shareholders can define their preferred set of parameters
+and thereby create a so called \emph{committee member} or alternatively vote
+for an existing committee member. The BitShares committee consists of $C$
+\emph{active} committee members.
+
+For each business parameter the protocol will calculate the difference between
+up- and down-votes ($v_\text{pro}-v_\text{con}$) for each active committee
+member and then take the median of the top $C$ active members:
+\begin{algorithmic}
+ \State // Derive active C committee members
+ \For{ i : active committee members }
+  \State member weight: $w[i] \gets v_\text{pro}-v_\text{con}$
+ \EndFor
+ \State $\text{members} \gets \Call{sort}{w}$
+ \State $\text{active} \gets \text{members}[0 \to C]$
+
+ \State // For each Parameter: derive median of active members
+ \For{ parameter : parameters }
+   \State $p \gets \Call{GetParameters}{\text{active}, \text{parameter}}$
+   \State $x = \operatorname{sort}(p[i])$
+   \State $\tilde p =\begin{cases}
+                        x[\frac{C+1}{2}]                                               & C \text{ odd}\\
+                        \frac {1}{2}\left(x[{\frac{C}{2}}] + x[\frac{C}{2} + 1]\right) & C \text{ even.}
+           \end{cases}$
+  \State $\text{parameter} \gets \tilde p$
+ \EndFor
+\end{algorithmic}
+Since, $C$ is a parameter as any other, the shareholders decide for the size of
+the committee.
+
+The BitShares ecosystem has a set of parameters available that are subject of
+shareholder approval. Initially, BitShares has the following blockchain
+parameters:
+%
+\begin{description}[leftmargin=4em,style=nextline]
+ \item[{fee structure}:        ] fess that have to be paid by costumers for individual transactions
+ \item[{block interval}:       ] i.e. block interval, max size of block/transaction
+ \item[{expiration parameters}:] i.e. maximum expiration interval
+ \item[{witness parameters}:   ] i.e. maximum amount of witnesses (block producers)
+ \item[{committee parameters}: ] i.e. maximum amount of committee members
+ \item[{witness pay}:          ] payment for each witnesses per signed block
+ \item[{worker budget}:        ] available budget available for budget items (e.g. development)
+\end{description}
+Please note that the given set of parameters serves as an example and that the
+network's parameters are subject to change over time.
+
+\medskip
+
+Additionally to defining the parameters any active witness can propose a
+protocol or business upgrade (i.e. hard fork) which can be voted on (or
+against) by shareholders. When the total votes for the hard fork are greater
+than the median witness weight $w$ then the hard fork takes effect.

content/bts-orga-witness.tex

@@ -0,0 +1,8 @@
+In BitShares, the witnesses' job is to collect transactions, bundle them into a
+block, sign the block and broadcast it to the network. They essentially are the
+block producers for the underlying consensus mechanism (see
+\cref{sec:consensus}).
+
+For each successfully constructed block, a witness is payed in shares that are
+taken from the limited reserves pool at a rate that is defined by the
+shareholders by means of approval voting.

content/bts-orga.tex

@@ -0,0 +1,3 @@
+Let us discuss the organization structure of the BitShares network when
+interpreted as a company. Some of these entities are associated with a cost for
+the business and need to be accounted for in profit calculations.