Lykke Wallet's private key distributed backup. Terms of Reference
The competition and voting have completed. Winners were determined by the citizens of Lykke City.
Days of the project
Jun 22 - Aug 30, 2017 (68 days)
Jun 22 - Aug 22, 2017
Jul 15 - Aug 22, 2017
Aug 22 - Aug 30, 2017
Every Lykke client has his / her own digital key that saves all the money kept in the Wallet. But the client may occasionally lose it, as well as backups of the digital key. This is the main problem that we want to solve.
Our method of private keys backup:
Digital key converted to 12 words.
Risk: Client may forget to save them.
The key is stored on Lykke server.
It is protected by the encryption client’s password so Lykke’s staff can’t steal it.
Risk: The client can forget his / her password.
The key is stored on client’s device.
Risk: The device can be stolen or broken.
About Social Recovery
Social Recovery allows you to recover your key, by relying on a network of trusted contacts for validation. These contacts can be friends or trusted institutions. This mode is usually reserved for potentially threatening circumstances.
Phase 1 (User).
At this point, pieces of key are generated and sent to the trustees via the public channel.
- Ability to set parameters (number of parts and weight of each part)
- Ability to encrypt each and every piece using a public key (of a friend/relative) to be sent through a public channel
Phase 2 (Trustee).
At this point, the trustee retains a piece of the key in the local database.
Phase 3 (User).
If there is a need to restore the key, user sends the request to the trustees.
- Generate temporary public key (with temporary secret private key)
- Send this temporary public key along with a text message to the trustees asking to help with the recovery
- Ttemporary secret private key is needed to safely get pieces from friends to the client (the pieces should not be visible to Lykke, although the pieces go through the server)
Phase 4 (Trustee).
At this point, the trustee receives a request for recovery. The system decrypts a piece of a previously retained key and encrypts a piece with a temporary public key.
- Sending through a public channel
Phase 5 (User).
At this point, the key is decrypted:
- Collecting the encrypted pieces and decrypting them
- Calculating the private key by pieces
The Terms of Reference shall meet the following requirements:
- Utmost clarity. Once the Terms of Reference are read, the developer should have no questions about the details of the software product that is being described. There should be no dual wording. The more specific the better.
- The Terms of Reference should have sufficient information to deliver it to the developer and start work.
- The sections of Terms of Reference should not contain conflicting information.
- The information must be well structured. Straight text is difficult to perceive and evaluate.
- The document should not contain extraneous information that is not relevant to the development of the system and that does not describe an aspect of its operation: keynotes, questions, colored highlights, etc.
- The future system should be fully described. In the case of phased development, the functionality of the relevant phase should be fully described.
- If the to-be-developed system has similar programs and applications, it is better to provide links to them.
- If the system involves integration with other systems, or if it uses other resources, you should specify them and provide all the necessary references and links.
- When describing the purpose of the system, you should provide basic user scenarios.
- The Terms of Reference should include examples of input data as well as data format to exchange between subsystems.
- The Terms of Reference should include examples of output data as well.
- Preferred development language is C#
The Terms of Reference structure
- General information about the project.
- The purpose and objectives of the development of the system.
- General requirements to the system.
- The composition and content of the work on system development.
- Control and acceptance of the system.
- Documenting requirements, including source code requirements;
- You should draw the architecture (skeleton) of the system and also describe the relationships between the subsystems.
The best participant can be hired by the Lykke Team.
About Lykke Wallet
Lykke is building a global marketplace where all asset classes and instruments can be traded. The exchange went live in June 2016 and is now in beta mode. Tradable assets include FX, bitcoin and Lykke coins (equity of Lykke). Lykke Exchange is using semi-centralized architecture. Matched orders are settled on the Bitcoin blockchain, where each successful trade between parties appears as a set of atomic colored coins swap transaction. The exchange does not take possession of the traded coins but needs to be trusted to match trades correctly.
|Username||reg. and Subm. Date||Result||Vote|
For this project, none of the submitted results matched our experts expectations, so we decided not to award the first prize.