IOTA Trinity Update – 10th August
Unsurprisingly, following on from last week’s update, the focus is still very much on preparing desktop beta release. Preparations needed for code signing (which ensures you don’t accidentally download a malicious clone) are near complete. All significant bugs discovered in alpha testing have been resolved, and the remaining minor visual bugs are being fixed. We have also made some adjustments to onboarding flow, to simplify wallet setup. The other remaining tasks before release include some finalisation of the Windows Proof of Work library, some additional code documentation/clean-up for open-sourcing the repo, and finishing implementation of SeedVault on mobile (see below). Meanwhile, we have been working on a simplified Mac tray app for quick access to account balances and history. And have also added send and receive OS notifications, so you can sit back, have a nice cold pint, and wait for your transactions to confirm.
As discussed in previous posts, we want to simplify seed back-up by moving towards standardised encrypted forms: SeedVault and EncryptedQR. The Trinity project was started with the idea of providing a seamless experience across mobile and desktop platforms. With the release of desktop beta, we would like to make seed migration as smooth and secure as possible. We want users to be able to export a SeedVault file from the mobile app, and then simply import that file into the desktop app. So, during the last week, we have been implementing SeedVault import/export on mobile. Owing to a lack of KeePass read/write mobile libraries with Argon2 support, it is necessary to fork an existing native library to add support. This will take some time, and in the meantime, we have come up with a solution relying on Node.js. The unfortunate consequence of this solution is that we will be unable to support < iOS 11 and armv7 architectures (i.e. iPhone 5, 5S, 5c, iPod Touch-5, iPad-4 and iPad Air). This is only temporary however, and when the native library is ready, we can add support for these devices/OSs again.
Another area we have looked at is replaying failed transactions. Currently, if a transaction fails in Trinity, we store the transaction trytes and allow the user to manually replay the transaction from the History page. The reason for doing this is that the inputs have already been signed and we risk revealing our private key(s) should we sign them again. Without storing failed trytes, a bad node could store the signature from the first attempt and deliberately not broadcast the transaction. If you were then to repeat this transfer, you would resign the inputs and the bad node would now have enough information to attempt to brute force your private key(s). In the current implementation, where we require the user to manually press retry, there is a risk that the user fails to ensure the transaction is broadcast there and then. If the user then uses another device, they could inadvertently lock spend from some inputs on the original device. So to mediate this issue, we have added automatic rebroadcasting from multiple nodes in case of failure. Additionally, if remote Proof of Work fails, it will be attempted again with a different node, before falling back to local Proof of Work. The main aim here is to ensure transactions are sent as and when the user issues them. The longer transaction trytes sit around unbroadcasted, the greater the chance we end up with locked funds/resigning of inputs through multi-device use.
If you have any questions about the project, come join the #trinity-discussion channel on Discord.