# GoShimmer Ledger State Logic overview: Value message attachment/storing: + Value Tangle attach to message Tangle solid event + UTXO attach to Value object solid event + From the solid payload we store the transaction inside the payload via its ID + if new we link the inputs of the tx to the tx ID + store reference of the outputs + if tx is new we store it --- Solidification + we submit it to the solidifier (`solidifyTransactionWorker`) + the tx is solid if either has been marked as solid or if the outputs that belongs to the inputs are solid and then check that the inputs are correctly consuming + balance check + check outputs validity + balance, color check + we sum up the unspent coins and check that the outputs spend all the consumed funds + we set the transaction metadata as solid + if its newly solid we need to book attachment --- **Branch inheritance rules:** A transaction inherits all the branch ids of its consumed inputs, by the following rules: * If there are multiple branches, the transaction either inherits its branch id from the most specialized branch (deepest common decendent) or it creates a new aggregated branch if there is more than one deepest common decendent. **Branch forking rules:** * If a transaction is not conflicting by any of its inputs, it inherits simply the parent branches of all of its inputs. * If the transaction is conflicting it creates a new branch, who's parent is determined by inheriting the branches of all of its inputs. If the transaction is creating a new conflict set for the first time, it also creates a branch for the first transaction which consumes the given shared input. **Booking:** + bookTransaction + we check that we are the first (or successive) consumer of a given input of the transaction. If we are the second consumer of a given input, we need to fork (create two branches, original first spend and second one). If we are the third or later we need to fork by creating only one additional branch for the current transaction. + we potentially aggregate multiple branches to compute our target aggregated branch or just a conflict branch (if it only refs. one parent branch). + if there are conflicts we fork by creating a new branch + we book the transaction and outputs to the target branch + we fork + abort if transaction was already finalized + update/create target branch identified by the conflicting transaction ID + abort if the branch existed already + move transactions to new branch + trigger event and return forked = true + onFork: load tx metadata and branch and if solidificationTime is older than averageNetorkDelay we like (set initial opinion) the first conflicting branch (FCoB rule) + onTransactionBooked: + if the transaction is conflicting we vote otherwise we use the fcob rule --- **Voting** Everytime a conflict set is created or expanded, the given branch of the transaction which created/expanded the conflict set, is automatically voted on. Subsequent transactions besides the first one, are voted on with a `disliked` initial opinion. (`onBookedTransaction()`) If a conflict set emerges and the first transaction is not finalized, then we will vote on it with either an initial `liked` opinion, if it has been unconflicting for more than the adverage network delay (6 seconds) otherwise with an initial `disliked` opinion. (`onForkOfFirstConsumer()`) When a vote is finalized, we set the `preferred state` of a given branch to that finalized opinion. If we set a branch to be not preferred, the un-preferred state propagates to the children of the branch. If a branch is set to be preferred, all other conflicting branches are un-preferred. --- Branch manager unit test: + should not accept a value message attaching on two conflicting value messages + check if branches are conflicting Value Tangle unit tests: + check that value messages are being stored + check that missing messages are being requested and solidified UTXO unit test: + check solidity + check validity (checkTransactionInputs) + checkTransactionOutputs + bookTransaction checks if we are branching off correctly and we are adding the conflicting inputs to the conflict sets (conflictingInputsOfFirstConsumer) + new non conflicting spend = no branch + first double spend = two branches + second or more double spend = new branch + check that `Fork` forks correctly + check that we are moving transactions to target branch correctly (`moveTransactionToBranch`) Other notes: + every balance has a color and a value + an input is a list of balances (check [UTXO spec](https://github.com/hmoog/protocol-rfcs/blob/master/text/0011-utxo-model/0011-utxo-model.md)) + aggregated branch can have multiple entry points ![](https://i.imgur.com/s7GuMAz.png) + moving transaction to branch: + an aggregated branch has multiple entry points + Tip selector + multiple lists of tips for each branch + getBalance is still missing: + you need all the ouputs of that address ## Flags + liked: all of its ancestor until master branch are liked, ==not finalized== + prefered: the first txn you see within conflict set + finalized: clean up all branches, to master branch
Last changed by  
 
Wolfgang Welz
173

Read more

Mnemonic Seed RFC

Feature name: mnemonic-seed Start date: 2020-03-11 RFC PR: iotaledger/protocol-rfcs#0010 Summary The IOTA protocol uses a 81-tryte seed to derive all the private keys for one account. This RFC describes a method to represent that seed as a mnemonic sentence - a group of easily comprehensible words. Motivation The used seed is a 384-bit or 243-trit random string. There are several ways to represent this in a human-readable form, but a mnemonic sentence is far superior to raw binary or ternary strings. These sentences can be written down on paper much more naturally or even be spoken over a phone. Furthermore, having raw strings tempts the user to copy and paste the seed. This practice opens new attack vectors such as theft or manipulation of the string in the clipboard.

6/26/2020
Ledger State Calculation

The ledger is modeled using unspent transaction output (UTXO). It consists of a set of transactions, where each transaction has inputs and outputs and consumes the outputs of a previous transaction with its inputs. The unspent transaction outputs, i.e. the outputs that are never consumed by a transaction, represent the actual ownership of the assets. The UTXO model can be defined more formally as follows: UTXO Graph A UTXO graph is a directed hypergraph $H = (V,T)$, where the vertices $v \in V$ are also called transaction outputs and the hyperarcs $t=(I,O) \in T$ with $I,O \subset V$, are called transactions. The tail $I$ of transaction $t$ is also called inputs of $t$, while the head $O$ is called outputs. The hypergraph $H$ must further have the following properties: There exists one designated vertex $g \in V$, called genesis, and no transactions have $g$ as an output, i.e. $deg^{in}(g) = |{T=(X,Y) \in A \mid g \in Y}| = 0$. For each vertex $v \in V \setminus {g}$ there exists exactly one transaction with $v$ as an output, i.e. $deg^{in}(v) = 1$. We call a UTXO graph $H = (V,T)$ conflict free, if for every $v \in V$ there exists at most one transaction $t = (I,O)$ with $v\in I$, i.e. $deg^{out}(v) \leq 1$.

5/14/2020
Bundle Mining Review

2/11/2020
Tip Selection

12/11/2019
Read more from Wolfgang Welz
Published on HackMD