Master not able to run so merging cbr branch.

.gitignore

@@ -21,3 +21,14 @@
 *.kate-swp
 gitversion.txt
 gitversion.tex
+
+# Node.js DEX
+dex/node_modules
+dex/package-lock.json
+
+# texstudio
+tagion_tech_paper.run.xml
+
+*.o
+*.html
+gossip

abstract.tex

@@ -1,5 +1,5 @@
 \begin{abstract}
 This paper describes an alternative implementation of a Distributed Ledger Technology (DLT) network compared to a classical network such as Bitcoin. Most other DLT networks use a Proof-of-Work consensus mechanism to secure the Byzantine Fault Tolerance (BFT) of the data storage. In the Tagion network, the BFT is based on the Hashgraph algorithm and data storage on a new type of Distributed Hash Table (DHT) which makes it efficient to maintain a distributed database and guarantee BFT. The Hashgraph algorithm is deterministic and not probabilistic, allowing ordering of transactions. The order of transactions combined with the Lightning Network and the Tagion matching and settlement protocol constitutes a Decentralised Exchange (DEX) protocol on the Tagion network. 
 
-To reduce the probability of the network being taken over by an evil group of actors, a new governance model is proposed, which does not rely on a central control or a group of master-nodes. It is built on the ideas of self-governance of common resources and democratic principles resulting in a Proof-of-People protocol and reputational scoring model that relies on the nodes engaging in dialogue with each other. 
+To reduce the probability of the network being taken over by an evil group of actors, a new governance model is proposed, which does not rely on a central control or a group of master-nodes. 
 \end{abstract}

bibtex.bib

@@ -73,3 +73,25 @@ @article{friedman_counter
 Number = {33},
 Year = {1970},
 URL = {https://miltonfriedman.hoover.org/friedman_images/Collections/2016c21/IEA_1970.pdf}}
+
+@article{libp2p,
+Author = {libp2p, githib team},
+Title = {Modular peer-to-peer networking stack},
+URL = {https://github.com/libp2p}
+}
+
+@article{wavefront_patent,
+Author = {Carsten, Bleser Rasmussen},
+Journal = {US20210227027A1},
+note = {Owner: i25s AG},
+Year = {2020},
+Title ={System and a method implementing a directed acyclic graph (dag) consensus algorithm via a gossip protocol}
+}
+
+@article{dart_patent,
+Author = {Carsten, Bleser Rasmussen},
+Journal = {US20210067330A1},
+note = {Owner: i25s AG},
+Year = {2020},
+Title = {Sparsed merkle tree method and system for processing sets of data for storing and keeping track of the same in a specific network}
+}

consensus_order_function.tex

@@ -0,0 +1,36 @@
+\section{Consensus order function}\label{sec:order_function}
+The code sample below shows the implementation of the consensus order function.
+\lstset{language=c++, numbers=left, numberstyle=\tiny, stepnumber=1, numbersep=5pt, tabsize=4}%, 
+\begin{lstlisting}
+bool order_less(const Event a, const Event b) @safe {
+	order_compare_iteration_count++;
+	if (a.received_order is b.received_order) {
+		if (a._father && b._father) {
+			return order_less(a._father, b._father);
+		}
+		if (a._father && b._mother) {
+			return order_less(a._father, b._mother);
+		}
+		if (a._mother && b._father) {
+			return order_less(a._mother, b._father);
+		}
+		if (!a.isFatherLess && !b.isFatherLess) {
+			return order_less(a._mother, b._mother);
+		}
+		if (!a.isFatherLess) {
+			return false;
+		}
+		if (!b.isFatherLess) {
+			return true;
+		}
+		bool rare_less(Buffer a_print, Buffer b_print) {
+			rare_order_compare_count++;
+			pragma(msg, "review(cbr): Concensus order changed");
+			return a_print < b_print;
+		}
+		assert(a.isFatherLess && b.isFatherLess);
+		return rare_less(a.fingerprint, b.fingerprint);
+	}
+	return a.received_order < b.received_order;
+}
+\end{lstlisting}

consensus_ordering.tex

@@ -1,30 +1,51 @@
-\subsection{Consensus Ordering}
-In the Tagion implementation of the Hashgraph algorithm, an Event is only allowed to point to one or none ``other parent'' which is called a ``father-event'' as shown om \cref{fig:consensus_order}. This strategy aids in solving the graph forking problem and simplifies the consensus ordering.\\
+\subsection{Consensus Ordering}\label{sec:consensus_ordering}
+In the Tagion implementation of the Hashgraph algorithm, an Event is only allowed to point to one or none ``other parent'' which is called a ``father-event'' as shown om \cref{fig:consensus_order}. This strategy aids in solving the graph forking problem and simplifies the consensus ordering.
 The ``self-parent'' is defined as a ``mother-event'' in the Tagion implementation. An event must have a mother-event but doesn't have to have a father-event.
 
-Each event points to the previous event called the mother-event, and some also point to another father-event. The mother-event is defined as the previous event from the same node. The father is an event sent via the gossip network from another node. \\
+Each event points to the previous event called the mother-event, and some also point to another father-event. The mother-event is defined as the previous event from the same node. The father is an event sent via the gossip network from another node. 
 
 The order $\Omega$ is calculated as:
-
-%\end{equation}
 \begin{equation}
  \Omega_{B,k+1} = max \big(\Omega_{A,k} , \Omega_{B,k} \big) +1
 \end{equation}
 
-The events in the epoch list are sorted by the order $\Omega$. If the order of two events is equal, the hash $h$ of the event is used to calculate the order.
+The events in an epoch list are sorted by the order $\Omega$. According to \cref{equ:order} which define if an event A must be ordered before a B event. If the order of two events is equal, then the nested function $l'$ \cref{equ:nested_order} is use to decided the order.\\
+A event is defined to be fatherless if the lineage of an event don't have a father back to the Eva event, and an Eva-event is defined to be an event without a mother and/or a father.
 The following expression is used to order the events:
 
-\begin{equation}
- {l}_{A,B} = 
+\begin{align}
+ {l}(A,B) & = 
     \begin{cases}
+         {l'}(A,B) &  	\text{if}  ~ ({\Omega}_{A} = {\Omega}_{B} )  \\ 
         {{\Omega}_{A} < {\Omega}_{B}} & 
-        \text{if}  ~ ({\Omega}_{A} \neq {\Omega}_{B} )  \\ 
-        H (    {h}_{A} \parallel {h}_{B} )  < H (    {h}_{B} \parallel {h}_{A} ) & 
         \text{otherwise}
-    \end{cases}
-\end{equation}
+    \end{cases} 
+    \label{equ:order}    
+\end{align}
+
+\begin{align}
+{l'}(A,B) & = 
+\begin{cases}
+{l}(A_{father},B_{father}) &  	
+\text{if}  ~ (\text{A has a father} ~ \&  ~ \text{B has a father}) \\ 
+{l}(A_{father},B_{mother}) &  	
+\text{if}  ~ (\text{A has a father} ~ \&  ~ \text{B has a mother}) \\ 
+{l}(A_{mother},B_{father}) &  	
+\text{if}  ~ (\text{A has a mother} ~ \&  ~ \text{B has a father}) \\ 
+{l}(A_{mother},B_{mother}) &  	
+\text{if}  ~ (\text{A is not fatherless} ~ \&  ~ \text{B is not fatherless}) \\ 
+0 &  	
+\text{if}  ~ (\text{A is not fatherless}) \\ 
+1 &  	
+\text{if}  ~ (\text{B is not fatherless}) \\ 
+{h}_{A} < {h}_{B} & 
+\text{otherwise (Only happens for none orderd event)}
+\end{cases} 
+\label{equ:nested_order}    
+\end{align}
+If parameter $l(A,B)$ is $'true'$ if event A is ordered before event B (see \cref{sec:order_function}).
 
-The parameter ${l}_{A,B}$ is $'true'$ if event A is ordered before event B.
+Note. An event which are fatherless is not allowed to contain a payload and an node must have participated in producing one epoch before the payload can be considered valid. 
 
 \begin{figure}[H]
  \centering

consensus_probability.tex

@@ -0,0 +1,74 @@
+\section{Gossip Model}\label{sec:gossip_model}
+
+\paragraph{Epoch consensus\\}
+
+In the following the probability for the Hashgraph-algorithm to reach an Epoch consensus within $H$ events consecutive is estimated in a simple model as follows.\\
+
+To estimate the bandwidth and the propagation delay simple simulation model has been implemented. 
+The network participants are given by the flowing parameters.
+\begin{itemize}
+	\item[$H$] is the number of event for a node to reach Epoch-consensus.
+	\item[$M$] is the total number of nodes which are available for the network (This includes active and passive nodes, not prospect nodes). 
+	\item[$n$] is the number of nodes which has not yet been seen by the current node. 
+\end{itemize}
+
+
+\begin{table}[H]
+	\begin{center}
+		\begin{tabular}{|l|p{4cm}|p{3cm}|}
+			\hline
+			Nodes $N$ & Round Factor $n_{round}$ & Bandwidth-Scale $B$ \\
+			\hline
+			11 & 5 & 171 \\
+			\hline
+			31 & 8 & 1396 \\
+			\hline
+			101 & 12 & 14918 \\
+			\hline
+			1001 & 16 & 1498538 \\
+			\hline
+			10001 & 20 & 149868334 \\
+			\hline
+			100001 & 24 & 14996214212 \\
+			\hline
+		\end{tabular}
+	\end{center}
+	\caption{Gossip simulation model} 
+	\label{tab:gossip_model}
+\end{table}
+
+From the simulation the following expression can be driven.
+The average events per round: 
+\begin{equation}
+n_{round} = 2.2 \cdot ln(N) 
+\end{equation}
+The average estimated time between epochs: 
+
+\begin{equation}
+t_{epoch} = K \cdot n_{round} \cdot t_{net}
+\end{equation}
+Whe the following is defined as:
+\begin{itemize}
+	\item[$N$] is the number of active nodes running the networks. 
+	\item[$K$] is the epoch scaling factor (Typical value of $K$ is typical a little larger than 3)
+	\item[$n_{round}$] is the average events for between round. 
+	\item[$t_{net}$] is the network delay. 
+	\item[$t_{epoch}$] is the average propagation delay per transaction. 
+\end{itemize}
+
+
+Estimated bandwidth scale-factor:
+\begin{equation}
+B = E_{size} \cdot N^2
+\end{equation}
+
+Estimated bandwidth requirement:
+\begin{equation}
+BW = \frac{B}{n_{round\cdot t_{net}}}
+\end{equation}
+
+\begin{itemize}
+	\item[$B$] is the average bandwidth scale factor used by a node.
+	\item[$E_{size}$] is the average memory size of an event including transaction data. 
+	\item[$BW$] is the average bandwidth used by a node.
+\end{itemize}

crypto_bill.tex

@@ -44,12 +44,12 @@ \section{Crypto “Bank” bill}
 
 
 Resulting in:
-\begin{equation}
+%\begin{equation}
  \begin{align*}
  Y_{bob} & = H(B_k \parallel y_{bob} ) \\
  B_{k+1} & = H ( V \parallel B_k \parallel t_k \parallel k \parallel T \parallel Y_{bob} )
 \end{align*}
-\end{equation}
+%\end{equation}
 
 
 The new bill is now written to the DART with key $B_{k+1}$:
@@ -67,13 +67,13 @@ \section{Crypto “Bank” bill}
  \end{equation}
 
 Each new bill is generated as:
-\begin{equation}
+%\begin{equation}
  \begin{align*}
  Y_{k+1,i} & = H ( B_k \parallel y_{k+1,i} ) \\
  B_{k+1,i} & = H ( V_{k+1} \parallel B_k \parallel t_k \parallel k \parallel T \parallel Y_{k+1} ), 
  ~ y_{k+1,i} \ne y_{k+1,j} ~ \text{for} ~ (i \ne j) \\
 \end{align*}
-\end{equation}
+%\end{equation}
 
 
 All new bills marked $B_{k+1}$ are stored in the DART as before, and the old bills are removed. \\
@@ -89,11 +89,11 @@ \section{Crypto “Bank” bill}
 \end{equation}
 
 The new bill number will be generated: 
-\begin{equation}
+%\begin{equation}
  \begin{align*}
   Y'_{k+1} & = H ( B'_k \parallel y_{k+1} ) \\
   B_{k+1} & = H ( V_a \parallel B'_k \parallel t_k \parallel k \parallel T \parallel Y'_{k+1} ) \\
  \end{align*}
-\end{equation}
+%\end{equation}
 
 These new consolidated bills are stored in the DART.

dart.tex

@@ -1,6 +1,6 @@
 \section{Distributed Database (DART)}\label{sec:DART}
 
-\abbrev{DART}{Distributed Archive of Random Transactions}
+\abbrev{DART}{Distributed Archive of Random Transactions} [Patent \cite{dart_patent}]
  is built to store and keep track of transactions in the Tagion network. The database efficiently handles the removal and addition of transactions in a secure and distributed manner.
 Each transaction is stored in a distributed hash-table using a cryptographic hash of the transaction T data. Each transaction is identified by a unique hash value h. The transaction is put into a table ordered by the numerical value of the hash.
 \begin{equation}
@@ -42,21 +42,26 @@ \section{Distributed Database (DART)}\label{sec:DART}
  \includegraphics[width=1.0\textwidth]{fig/dart_tree_bw.eps}
  % dart_bw.eps: 17766x12625 px, 300dpi, 150.42x106.89 cm, bb=0 0 4264 3030
  \caption{The data structural layout of DART database}
- \label{fig:dart}
+ \label{fig:dartsector}
 \end{figure}
 
 
 
-\subsection{Sparse Merkle Tree}
+\subsection{Sparse Merkle Tree}\label{sec:SMT}
 The data in a section is mapped using a \abbrev{SMT}{Sparse Merkle Tree} which makes it efficient to add into and remove archives from the Merkle tree. \\
 The hash point into the DART is divided by rims. Rim zero is the most significant byte (MSB) of the hash fingerprint of the archive. Rim one is the next byte in the hash etc. \\
 In the current implementation of the DART, the first two rims are used as the section index. Thus the DART has a total number of indices $2^{16} = 65536$ which is equivalent to the two bytes unsigned number. \\
 Each section stores the archive in a hash table. An SMT is used as a look-up table, and each rim is sectioned into a sub sparse Merkle tree. This means that rim two is the first SMT and rim three is the second SMT etc. \\ 
 As a comparison, a traditional Merkle tree with $2^{24} = 8^3 \approx 16 \cdot 10^{6}$ Archives. Calculating a full Merkle tree requires the calculation of around $32 \cdot 10^6$ hashes. By contrast, using an SMT with $16 \cdot 10^{6}$  archives mean just around 2000 hashes have to be calculated.
 
 \paragraph{Core protocol updates\\} 
-The DART will be used for protocol updates by the following consensus. One or more nodes will need to run the new protocol update in a parallel DART containing the same transaction information as the current accepted DART. The new DART will have a new Bull's eye, and this will result in a fork of the Bull's eye chain. When the majority of the nodes run the newly upgraded nodes, they can decide to drop support for the old DART and run the new DART. When enough nodes stop running the old DART, it will not be able to reach a consensus, and the upgrade has completed.
+The DART will be used for protocol updates by the following consensus. One or more nodes will need to run the new protocol update in a parallel DART containing the same transaction information as the current accepted DART. The new DART will have a new Bull's eye \abbrev{Bullseye}{DART Merkle Root}, and this will result in a fork of the Bull's eye chain. When the majority of the nodes run the newly upgraded nodes, they can decide to drop support for the old DART and run the new DART. When enough nodes stop running the old DART, it will not be able to reach a consensus, and the upgrade has completed.
 
 \paragraph{DART garbage collection\\} 
 A garbage collection script will run every (G) epoch and remove all the bills which are older than a specified date. Bills that have not been used for a long period will be burned, which ensures that the system does not contain dead bills/money.
 It is the owner's responsibility to recycle their bills before the expiry date.
+
+
+\paragraph{Unpredictable Deterministic Random\\}
+The merkle root \bfit{Bullseye} is used as seed for the \abbrev{UDR}{Unpredictable Deterministic Random}, which is used in the different algorithmic consensus for the network.
+

dex/bid_sales_table.tex

@@ -7,10 +7,10 @@
 \hline
 26 & BTO & 87ACL & 134 & 10 & 0.0746 & 13.4000 &    &    &    \\
 \hline
-7 & BTO & 205ACL & 145 & 11 & 0.0759 & 13.1818 &    &    &    \\
-\hline
 5 & BTO & 217ACL & 145 & 11 & 0.0759 & 13.1818 &    &    &    \\
 \hline
+7 & BTO & 205ACL & 145 & 11 & 0.0759 & 13.1818 &    &    &    \\
+\hline
 21 & BTO & 716ACL & 134 & 11 & 0.0821 & 12.1818 &    &    &    \\
 \hline
 33 & BTO & 226ACL & 144 & 12 & 0.0833 & 12.0000 &    &    &    \\

dex/bid_sales_table_executed.tex

@@ -7,10 +7,10 @@
 \hline
 26 & BTO & 87ACL & 134 & 10 & 0.0746 & 13.4000 &    & 53.60ACL & 3 \\
 \hline
-7 & BTO & 205ACL & 145 & 11 & 0.0759 & 13.1818 & 205.00ACL &    & 6 \\
-\hline
 5 & BTO & 217ACL & 145 & 11 & 0.0759 & 13.1818 & 217.00ACL &    & 4 \\
 \hline
+7 & BTO & 205ACL & 145 & 11 & 0.0759 & 13.1818 & 205.00ACL &    & 6 \\
+\hline
 21 & BTO & 716ACL & 134 & 11 & 0.0821 & 12.1818 & 323.08ACL &    & 11 \\
 \hline
 33 & BTO & 226ACL & 144 & 12 & 0.0833 & 12.0000 &    & 226.00ACL & 12 \\