Friends!
Today, we have decided to publish an announcement dedicated to positive news. Unlike several previous announcements which were devoted to our struggle for the attention of BitShares stakeholders (and the budget for our wonderful project), we want to congratulate everyone on getting back on track. A few days ago, the BitShares platform once again demonstrated its viability and technical excellence, which inspire us all to continue development on the blockchain ecosystem and promote its ideas to the masses.
However, today we are pleased to share that we have finally received the support of several leading BitShares stakeholders, and our project has received full funding from the blockchain. We recently published a public test version of the new interface connected to the BitShares test network, as well as mock-ups designed for mobile devices.
We admit that the protracted period of almost complete lack of funding will likely result in adjustments to the timing of the implementation of the final product. Perhaps we will come up with a proposal to extend the worker, or we will come up with a new working proposal, including those works that we were forced to be postponed until better times.
Nevertheless, the project continues, the product requires quite specific outlines and often pushes us to rather radical reflections and ideas for further development.
One such idea is the rejection of the built-in storage of personal keys, and we would like to explain the motivation of this (so far only possible) solution.
In the process of developing a new user interface for the official BitShares application, we faced many interesting tasks and unexpected problems, one of which is that the current version of the application doesn’t have any ability to manage the user's personal keys. Indeed, now we can either not keep a permanent copy of our keys at all, using the so-called Cloud Wallet, or use a special file for storing the keys - the so-called bin-file.
The advantage of Cloud Wallet is its simplicity - in fact, the user logs in to the system (creates transactions) using only his account name in the BitShares blockchain and a password. However, this can be a rather risky method of authorization: the user can forget his password or an attacker can get access to the user's tools if the password is not complicated enough.
Storing personal (private) keys in a bin-file is much safer for protection against hacking, but also has its drawbacks: the user can lose the bin-file, forget to make a timely backup, or forget the password from the file itself. In addition, in the current version of the user interface there is no ability to manage the contents of the bin-file, which can lead to confusion and inadvertently lost keys - one can simply confuse bin-files with other files and delete or transfer the wrong file into the wrong hands
Today, we have come close to designing the business functions of the new application, which, among other things, includes managing access rights to user accounts and assets in the blockchain. We understand that in order to meet the needs of ordinary users, a more obvious and simple authorization mechanism with a password will suffice - and we implement and optimize this authorization method in the first place. However, for more complex scenarios, the user needs a simple, reliable, and secure tool for managing private keys.
Unfortunately, the storage of personal keys in the browser is very difficult to make completely secure - therefore, increasingly, users of other platforms prefer to completely eliminate direct contact of web applications downloaded via the Web with keys and give preference to external (with respect to the web application of one or another dApp) managers keys.
Another obvious advantage of separating keys from the application itself is the ability to expand the product line that interacts with the blockchain in safe mode without having to copy the private part of the keys to the web interfaces of each application. For example, a voting tool or a simple form of sending funds cannot be implemented in an optimal (from a security point of view) method unless the user's keys are placed in a separate safe-application which provides authorized access to the entire product line without disclosing the most sensitive part of any crypto product: personal user keys.
In the BitShares / Graphene ecosystem today there are several solutions for storing private keys separately from user applications, including Beet and WhaleVault. These solutions have pros and cons, but in general, they are quite suitable for use and integration with the new application that we are developing as part of the Rossul / GrapheneLab project. If you choose between the repetition options of the BitShares classic interface to work with private keys and the use of more secure and reliable options offered by Beet and WhaleVault, we would, of course, prefer the latter.
It's no secret that a certain generally accepted approach to working with keys has emerged in the EOSIO ecosystem - almost any new dApp on the EOS main chain or on other EOSIO forks, by default, allows users to use the keys stored in Scatter. Scatter is currently the mainstream solution, which is preferred by most users of crypto and blockchain products, including the rapidly growing Gaming, Gambling, Exchange (including DEX).
We believe, an attempt to integrate the key format and BitShares interaction protocol into Scatter, if successful, will not only simplify the life of the BitShares ecosystem users and provide an opportunity to develop the widest product line based on this blockchain, but also potentially expand the audience of BitShares users by attracting new members who have already begun their acquaintance with the world of crypto and blockchain projects in a parallel ecosystem.
Taking into account the current issues regarding the development of the BitShares ecosystem and our attempt to find optimal solutions to the tasks of our main project, we suggest including work on integrating Scatter with the new official BitShares application into the current project's scope or formulating a new working proposal for stakeholders. The question of choosing a specific contractor for research and direct integration, as well as the project format (bounty or direct financing of a specific team) is less relevant - it is important for us to know that future versions of BitShares products will be able to meet increased requirements for convenience and security and will ensure sustainable growth of BitShares ecosystems.
We urge those among you who have not yet voted for our worker proposal to do so. Every voice counts!
