Development

GitHub metrics:

Development is ongoing. Commits on public GitHub appears regularly, several times a day.

Developer activity (from Coinlib.io):

The team releases the results of the Trinity audit conducted by world-leading cybersecurity firm SIXGEN. A security assessment of all desktop and mobile versions (Windows, Mac, Linux, iOS and Android) revealed an overall LOW risk of compromise from external attackers. Wallet security is at the core of the Trinity team’s approach and they maintain high standards across all app areas. The audit results validate this approach and confirm the overall security of Trinity as a method for safeguarding IOTA tokens. The report can be found here.

The audit was performed in a two-stage process. First SIXGEN conducted manual and automatic analyses of encryption methodologies, sensitive data handling, network and OS interfacing, alongside emulation of real world attack attempts. And provided remediation steps for their findings (all of low and informational risk level). Then, working together with the SIXGEN team members, the Trinity team applied the suggested remediations. And finally, the SIXGEN team reassessed and retested those remediations.

“We reviewed the security of the Trinity wallet and determined it to have a low risk of compromise from external threats,” said Ethan Dietrich, CEO, SIXGEN, “It is clear the Trinity team takes security very seriously and has applied best practices throughout the wallet’s development.”

Trinity beta is available for download on all major mobile and desktop platforms.

A simple explanation of Azimuth (also known as NB-PoW) — A different approach to proof of work that IOTA team is working on as part of their long-term vision for IOTA. This post is the result of a collaboration among Marcos Andrade, Philipp Blum, Andrew Brough, Jake Cahill, Dave de Fijter, Sabri Goldberg, Sergey Ivancheglo, Igor Nielsen, Navin Ramachandran, and Samuel Reid.

The Bar — Explained

In Azimuth, nodes can send transactions to nearby neighbors through the air. On receipt, the neighbors make a note of which direction a transaction came from before processing it.

If, during the same round, a neighbor receives another transaction from the same direction, it will treat it as spam and ignore it.

The idea here is that, during a round, a node cannot occupy enough physical space to send lots of spam from different directions and overwhelm the neighbor.

Because nodes limit transactions by direction, they don’t need to know who their neighbors are in advance. Instead, they can accept transactions from any node as long as they don’t send them from a direction that’s already been used during a round.

An 8-second round at the bar

Why are the team building Azimuth?

When anyone is free to take part in a network, some users turn out to be dishonest. An example of a dishonest user is one that sends many transactions to a node to try and take it offline. These transactions are known as spam.

To discourage spam, IOTA uses proof of work (PoW), which links transactions to a limited resource: computational power. This way, sending spam transactions costs time and energy.

For devices such as laptops or servers that have access to the Internet and plenty of power supply, PoW is easy to do. But, devices on the IoT are often small and power-constrained, so this extra use of power is wasteful.

Instead, a way for these IoT devices to protect themselves from spam without wasting their energy on PoW is needed.

With Azimuth, IOTA can replace computational power with direction (a limited number of directions exist, so they link each transaction with a direction).

When a device uses Azimuth, it doesn’t need to do any work. The action of sending a transaction from a given direction is enough.

By using this approach, small IoT nodes can save energy, extend battery life, and avoid doing those troublesome push-ups.

Comparison of energy use between proof of work and Azimuth

Want to know more?

In this post, the team discusses how Azimuth can use direction to limit transactions. For example, Li-Fi networks could use optical sensors to detect direction. But, Azimuth does not enforce any specific implementation. For example, radio networks are free to use antennas to detect signal strength and distinguish devices by distance.

As they mentioned before, all permissionless networks have dishonest users. In the case of Azimuth, these users could try to fake their direction or their distance to be able to send more transactions during a round. This type of attack is called a Sybil attack.

Today, devices already have the means to detect some of these attacks through radio resource tests, which would be prohibitively expensive to cheat. For example, a radio device would need many transmitters, and a LiFi device would need to be large enough to occupy lots of physical space.

Client libraries and IRI with networking rewrite update:

Many things have been baking in IOTA IRI and client lib development efforts the past few months and the team feels like it is time for another update to highlight what is coming. The team goes over some of the breaking changes coming with the networking rewrite.

Client libraries

The team has released the stateful versions of client libraries back in April. Since then they have worked on improving the documentation and most recently, they have started ramping on the new MAM protocol.

MAM will also be the focus of the upcoming weeks. All the libraries — Java, JS, and Go will provide wrappers for the new MAM protocol that has been in the works for a few months now. You can take a look at the alpha of the new MAM here.

IRI

A lot has been happening in IRI. There is a version 1.7.1 coming this week. This version introduces a large number of different fixes and changes. One of the fixes the team believes should improve the issue where the node got stuck at ‘repairing corrupted milestone`. This issue has proven very difficult to debug.

Another important change in IRI is a new tip selection timeout mechanism. The node stops the tip selection process if it is not able to return a response in a given time. This is controlled by the `TIP_SELECTION_TIMEOUT_SEC` configuration parameter. The default timeout is 60 seconds.

There are also some breaking changes introduced by the unification of the behavior of boolean configuration flags. All boolean flags now require explicitly passing a parameter to make their behavior clearer. Also, in the past, it was possible to overwrite the values if you had passed the same value in both the configuration file and the CLI.

Many changes also happened under the hood. For example, the team has made the API much easier to work with in code. This will help them whenever they are extending or making changes to the APIs. They has also improved the whole release process as they aim to shorten the release cycles in the future.

A full list of changes will be available in the release on GitHub as usual.

A shout out also goes to IOTA community for their contributions. For example, Viossat changed the hashing algorithm for caching incoming transactions.

IRI networking rewrite and preparing for upgrade

Another large effort in IRI is the complete rewrite of the networking layer. The code has been rewritten from the ground up, with a lot of significant changes.

Part of the process to rewrite the networking protocol was setting up the Iota Community Committee (ICC). A group of representatives voted in by the community. The members of the ICC then set up a network on which the new code is being tested.

The team would like to release IRI with the new networking in the second week of July (July 8–12).

Read more on how to prepare for the new networking >>>

Also, you can see a description of the networking rewrite changes in this pull request.

The new build brings a number of crash and bug fixes. Notably, migrations from < 0.5.0 versions to latest have been fixed.

“We reviewed the security of the Trinity wallet and determined it to have a low risk of compromise from external threats,” said E. Dietr., CEO, SIXGEN, “It is clear the Trinity team takes security very seriously and has applied best practices throughout the wallet’s development.”

Download it here.

Fix: Migration not successful when migrating from 0.4.x and below to latest (#1832)

Fix: Incorrect already spent from address errors on transaction retry (#1835)

Fix: Incorrect transaction failure alert when successfully broadcast (#1835)

Fix: Quorum being conducted on transaction account syncs when explicitly turned off (#1835)

Fix: Error-related crashes (#1833)

Update: Add remote node list endpoint back-ups (#1811)

Update: Add more verbose error log messages (#1834)

Update: New translations (#1826)

Closes #1538, #1386, #1815, #1422

Trinity Mobile 0.7.3 (74) has been released. Like the latest Desktop version, the new build brings a number of crash and bug fixes. Notably, migrations from very old versions to latest have been fixed.

Fix: Migration not successful when migrating from very old versions to latest (#1832)

Fix: Handle exception if salt is missing from keychain (#1772)

Fix: Incorrect already spent from address errors on transaction retry (#1835)

Fix: Incorrect transaction failure alert when successfully broadcast (#1835)

Fix: Quorum being conducted on transaction account syncs when explicitly turned off (#1835)

Update: Add remote node list endpoint back-ups (#1811)

Update: Add more verbose error log messages (#1834)

Update: New translations (#1826, #1838, #1853)

Closes #1538, #1386, #1815, #1422