Development Update 3
--
The primary focus of last week’s development was continuing to work on the core functionality of the wallet, most of which is nearing completion. A major feature added to the web wallet is two factor security while still keeping the user in full control of their atmos. Our implementation in concept is modeled after the two factor wallet in the popular Bitcoin wallet Electrum.
Next week, we will be looking to start implementing the core functionality of AFIX as a plugin to the blockchain interface. As there was examples of the block explorer in Development Update 2, we are aiming to have a few examples of content related to AFIX in the next update.
Lastly, we need more testers! If you want to get involved join our Discord and help speed up the development process by helping with testing and bug reporting. No technical knowledge is required, simply being able to test certain features and cross-referencing bugs with our issues list to see if they’ve already been reported is the only requirement!
Web Wallet
Multisig 2FA Wallets
We have now introduced 2FA wallets which allows the user to be even more secure while managing their atmos. The fundamental concept of implementation was previously published on GitHub early on.
In a regular wallet, when you generate your mnemonic (12 word seed) your addresses are then derived from this seed. However, if someone were to get a hold of your 12 word seed this would likely result in loss of your atmos.
In a 2FA wallet, when you generate your mnemonic, you also generate a master key. The user then sends the public key of their master key to the trusted server (Novus) and is then given a Google Authenticator secret for two factor authentication purposes. The user should store their master key safely and offline.
When the user signs into their 2FA wallet they enter their mnemonic in the same way they would signing into a regular wallet and their two factor code. They do not need to re-enter their master key because the trusted server has a stored copy of the public key of the master key paired against a hash of the user’s mnemonic.
All addresses in the wallet are 2-of-3 multisignature addresses that are composed of a key derived from the mnemonic, the master key, and the trusted server’s key. A transaction is signed from your mnemonic derived key and the trusted server’s key provided you enter the correct two factor code.
Should the trusted server be hacked and possibly even lose its keys, user coins are not affected. This is because the server only has knowledge of 1-of-3 of the keys. In the case of the trusted server losing its keys, the user then relies on their backed up master key for the second signature instead of the trusted server’s key.
While this is a great addition in terms of security going forward, since the web wallet of the blockchain interface is still under development it still should not be used for managing any considerable amount of coins.
The implementation is part of the wallet plugin of the blockchain interface and there by open source for any projects wishing to use it as reference for their own similar implementation.
Trustless
The issue with client-side transaction signing has now been resolved and transactions are now constructed entirely client side and only the final signed copy is given to the server to relay to its peers.
In the case of a two factor based transaction, first the transaction is signed by the user and then the trusted server co-signs the transaction. The final transaction is then given to the server the blockchain interface is connected to relay as a regular transaction would be.
All sensitive information is now kept entirely client side as it should be and this is entirely auditable as the source code for the client is available on GitHub.
