# Bundle Mining Review ## [IOTA Common](https://github.com/iotaledger/iota_common) [bundle_miner.h#L32](https://github.com/iotaledger/iota_common/blob/8cb88f3ff3188acc45457c80d47a369127ff9aaf/utils/bundle_miner.h#L32) `optimal_index_found_by_some_thread` must be made atomic to avoid race conditions as it is shared among multiple threads. [bundle_miner.c#L122](https://github.com/iotaledger/iota_common/blob/8cb88f3ff3188acc45457c80d47a369127ff9aaf/utils/bundle_miner.c#L122) This will overflow. `obsoleteTag` is 27 trytes, i.e. 128 bits. Storing it in a `uint64_t` (and adding count) will lead to arbitrary tags. Instead, just always start with `start_index = 0`. [bundle_miner.c#L57](https://github.com/iotaledger/iota_common/blob/8cb88f3ff3188acc45457c80d47a369127ff9aaf/utils/bundle_miner.c#L57) `mining_threshold` seems to be defined as $\log_3$ of the expected number of tries for an attacker. This logarithm is very unintuitive! The PoW difficulty is defined by powers of 3, but this threshold is not comparable to the PoW difficulty as it uses different hash function among others. It would be better and easier to maintain/understand to pass `num_trials_mining_threshold` (expected number of tries) directly. [bundle_miner.c#L76-L91](https://github.com/iotaledger/iota_common/blob/8cb88f3ff3188acc45457c80d47a369127ff9aaf/utils/bundle_miner.c#L76-L91) The if-clauses are completely unnecessary and don't do anything. Also the computation can be simplified. ```C double bundle_miner_probability_of_losing(byte_t const *const hash, uint8_t const security) { // compute the probablility that a random (not normalized) hash is tryte-wise <= the given hash double p = 1.0; for (size_t i = 0; i < security * NORMALIZED_FRAGMENT_LENGTH; i++) { p *= (double)(normalized_hash[i] - TRYTE_VALUE_MIN + 1) / (double)(TRYTE_VALUE_MAX - TRYTE_VALUE_MIN + 1); } return p; } ``` :::info Remark: Especially with security level 3 the probability `p` will get very small which might cause numerical issues. An alternative score computation would be for `(H,M) = (candidate_normalized, ctx->bundle_normalized_max)`: ``` score(H,M): s = 1.0 for i = 0 to security * 27: if H[i] > M[i]: s *= (14 + H[i])/(14 + M[i]) ``` This will result in exactly the same order as the probability but avoids small factors. ::: [bundle_miner.c#L58](https://github.com/iotaledger/iota_common/blob/8cb88f3ff3188acc45457c80d47a369127ff9aaf/utils/bundle_miner.c#L58) `optimal_index_found_by_some_thread` is not a good name, since only the *threshold* is reached. :::info Remark: It might make sense to add an early termination criterion, when an *optimal* index is found, i.e. `candidate_normalized` is tryte-wise less or equal to `ctx->bundle_normalized_max`. In this case, the new bundle will reveal *no* additional information at all. However, this is very unlikely and will only happen if multiple hashes have been signed already. ::: [bundle_miner.c#L105](https://github.com/iotaledger/iota_common/blob/8cb88f3ff3188acc45457c80d47a369127ff9aaf/utils/bundle_miner.c#L105) Rounds `count` up to the nearest multiple of `num_ctxs`. When `count` is already divisible it adds `num_ctxs`. Also, this will lead to overflows when a value close to `UINT32_MAX` is passed. This is not happening with the current parameters, but as an overflow could lead to unsecure bundles, those cases should be caught. [test_bundle_miner.c#L63](https://github.com/iotaledger/iota_common/blob/8cb88f3ff3188acc45457c80d47a369127ff9aaf/utils/tests/test_bundle_miner.c#L63) There is only one test for the actual mining and it only checks that the mined index matches. Since this is security relevant, it would be nice, to have better and more conclusive test cases here. For example: - Do not check the index, but check that the probability is indeed lower than for other indices. - Test for edge-cases like `MMM...MMM`, `NNN...NNN`, ... - Add a tests for the threshold termination. - Test more hashes. - ... ## [iota.js](https://github.com/chrisdukakis/iota.js/tree/feat/bundle-miner) https://github.com/chrisdukakis/iota.js/blob/82d5d6eb3ac858e6eb7dc361c07d5ac1c7a311e4/packages/bundle-miner/src/index.js#L19-L31 The function name is wrong and dangerous. It just computes the tryte-wise *maximum* of several hashes. - Change the function name to `maxHash`. - `MAX_TRYTE_VALUE` not needed, just compute the maximum. ## [trinity](https://github.com/laumair/trinity-wallet) https://github.com/laumair/trinity-wallet/blob/291091e2930ec7f7a2397c54ac3d036b32b6b575/src/desktop/src/libs/SeedStore/SeedStoreCore.js#L61 Where are those parameters coming from? - `miningThreshold`=40 corresponds to roughly 10^19 tries an attacker needs. This seems very high: Breaking security=1 with one known hash takes only 10^13 tries. Breaking security=2 with two known (random, not mined) hashes takes only 10^16 tries. Does this parameter ever lead to an early termination? Or is `count` always reached first? - `count`=10^8 seems rather arbitrary. Especially since the threshold does not seem to be very relevant this `count` defines the sole termination criterion. I see two potential issues with this: - on slow machines, computing `count` hashes can take a long time a "freeze" the mining - on fast machines, a higher security would be desirable and achievable - `isLedgerAccount ? count * 3.13 : count` what is this magic 3.13? If this is because the entire bundle hash needs to be `M` free, then this should be $\frac{3}{\texttt{security}}$. I think, these parameters should be revisited: - Carefully think about the `miningThreshold`: - How many hashes can a strong machine compute in one month or similar and use that value. - Make this dependent on the current probability, like 75% security that the currently known hashes provide. - No threshold at all, find the best hash possible within given timeout/count. - Combine the `count` termination criterion with a timer (or user interaction) to increase mining on very powerful hardware and decrease on lower power hardware.
Last changed by  
 
Wolfgang Welz
252

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
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

5/8/2020
Tip Selection

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