Written in front: Losing wallet passwords or private keys is a common problem for cryptocurrency users. Is there a way to recover lost keys while minimizing trust? This is exactly the direction that Ethereum co-founder vitalik and others are exploring, and they have written a new EIP ( Ethereum Improvement Proposal) and named it the Secret Multisig Recovery scheme.
Yesterday, Peter Schiff, a well-known gold enthusiast and crypto skeptic, claimed on Twitter that his wallet had lost his password and was unable to access his bitcoin.
Schiff went on to add:
- Chasing up and killing! Google Trends data shows that investors always want to buy after rising
- Does Bitcoin cause an environmental crisis?
- Getting started with blockchain: Why do bitcoin transfers have to wait for 6 confirmations before they arrive?
- 150,000 bitcoin "ammunition" has been prepared, bitcoin whales have seized market opportunities?
- Where will the safe-haven funds go after Black Monday?
- It is said that many people do not buy bitcoin because of them?
"So now my Bitcoin is essentially worthless and it has no market value. I know that owning Bitcoin is a bad idea, but I never realized it was so bad!"
After Schiff announced his losses on Twitter, the cryptocurrency community quickly began discussions. For example, Anthony Pompliano, co-founder and partner of Morgan Creek Digital, asked if he had forgotten his password, and Schiff responded by saying: "It was my wallet that forgot the password."
The unsightly Pompliano had to explain patiently:
"The software just executes commands issued by humans. It can't 'forget' anything. Just email me and I will do my best to help you recover the lost Bitcoin."
However, according to Schiff's answer, his bitcoin is basically hopeless, and he mentioned:
"It was Eric Voorhees (Note: CEO of ShapeShift) that helped me prepare the wallet, and even he felt I could do nothing. If you have any ideas, welcome to try."
Seeing this, readers may think this is a very sad story. A cryptocurrency skeptic managed to try Bitcoin, but lost them because he forgot his password. And if he backs up the private key in multiple places, even if he forgets the wallet password, he can access his wallet through the private key.
Of course, some people may think that this is a profound lesson, which reminds us to develop related technologies to provide security for similar people.
For example, vitalik co-founder vitalik commented:
"I am disappointed that people use 'cryptocurrency is cryptocurrency, and your job is to be very careful to write backup seeds in three places' to answer this question. We can and should create better wallet technology, Security becomes easier to implement.
For example, here is a social recovery proposal: https://t.co/tuSbHhXKgd?amp=1 ” So what exactly is the social restoration proposal mentioned by God V?
Let's take a brief look below.
EIP 2429: Secret Multisignature Recovery
Author: Ricardo Guilherme Schmidt (firstname.lastname@example.org), Miguel Mota (@Miguel Mota), Vitalik Buterin (@vbuterin), naxe (@ngmachado)
Requirements: EIP (137, 191, 831, 1271, 1344, 2470)
In general, a bad experience with cryptocurrencies is the loss or exposure of private keys, which can lead to irreversible situations.
Social recovery is considered as an option for decentralized recovery of account contracts. However, the use of social recovery brings human factors, which are usually the main reason for the vulnerability of security systems.
The main risks of social recovery are:
- Collusion: If some users know that they are part of a recovery, they may be interested in the execution of a recovery attack;
- Targeted attack: An external agent may know the owner of the recovery and target the weakest point needed to perform a recovery attack;
- General exposure: If an attacker manages to infect large user infrastructure dependencies and gain access to multiple identities, it may also have side effects on unaffected users by restoring them;
- Simulated attack: A targeted attack can understand a user's situation and simulate that user to their social peers to perform a recovery attack. This becomes even more interesting as AI research is able to "deeply fake" other people's voices and facial movements.
Although there is no perfect solution to all of these issues, our goal is to implement a "trust minimization" controller contract and enable interoperability for different wallets that users may use.
It is reported that the standard proposes a method of defining a list of addresses stored in the Melkle tree. These addresses, together with their weights and the user's personal secrets, will form a secret set, which can be used without directly endangering the user. Public because it still requires manual verification of the total threshold in the address list.
This secret set can be saved, for example, stored in web2 cloud storage without seriously affecting security, which is very useful for users who do not trust themselves but do not want to trust certain specific entities.
The user secret will never be displayed in the chain, only a nonce hash is displayed, and it will increase every time it is restored. The recovery setting obtains a hash of a hash of this hash secret nonce. This double hash method is used to mathematically prove that the person requesting recovery knows the secret without revealing it.
According to the proposal, users can configure recovery by providing a secret (
user_secret_data ) and a weighted address list (
user_secret_data can be semi-private information that users can guess. The
user_secret_type is an optional random large integer, and it is exported with the
The total weight of the address list must be greater than the threshold, and the threshold is a constant:
THRESHOLD = 100 * 10^18 .
The standard defines several methods for generating predictable user secrets.
Biometrics (such as fingerprints, faces, and pupils) should be used when they are available. This is the simplest method.
In the absence of biometrics, a standard set of questions that are usually only known to users can be used to generate users' secret data. All optional default fields are:
Full Name ,
Birth Date ,
Mother Name ,
Mother Birthdate ,
First Love's Name ,
First Pet's Name ,
Childhood Nickname .
The password derivation method is similar to the detailed form method, but it requires the user to enter only a few things:
Full Name and
The user will define a list of guardian accounts, which will be populated from the user's contact list. It should be convenient to import the options and enter an address, as shown in the figure:
After selecting a guardian, the user will be prompted to define the weight of each guardian:
These addresses are stored in a standard merkle tree, but each cotyledon must be hashed with
merkle_root is hashed into a standard merkle tree, which consists of
address_list cotyledons of the form
keccak256(bytes32(hash_to_peer), uint256(weight), boolean(is_ens), bytes32(ethereum_address)) .
The solution supports the ENS domain name. When a guardian owns an ENS domain name, the ENS domain name should be used. According to EIP-137, if ENS domain name is used,
is_ens must be "true".
The address in the list can be an account contract. If it is an account contract, you can directly call the approval function or provide an EIP-1271 signature. If they have external accounts, the ecrecover logic is applied, but they can also directly call the approve function.
weight sets the degree of approval of this address value relative to the
User secret data hash
- For multiple users,
recovery_contractmay be the same, which is the shared secret multi-signature contract address that the user is using;
user_secret_datais pure format byte data of user data, it is never exposed and will not be saved. When
private_hashis unknown, a request should be made to the user;
keccak256(user_secret_data), it is never exposed and can be derived using a secret set. This can be reused in all restores;
merkle_rootis obtained by hashing an ordinary merkle tree, and it will be exposed when it is executed;
weight_multiplerdefines how many individual weights need to be multiplied to reach
keccak256(private_hash, address(recovery_contract), recovery_contract.nonce(user_address)), it is only exposed at execution time, and each recovery is unique, also known as "display hash". Nonce and recovery contract addresses are used to allow reuse of
keccak256（hash_to_execute）, which is exposed when the authorization request is restored. It is used to prove that the user knows
merkle_rootby exposing the
public_hashseed. This is also called "partial leaking hash";
keccak256（hash_to_peer，merkle_root，weight_multiplier）. It is public after configuration and can only be used once. This is also used to prevent replay of execution. After successful execution, you must use
Recover secret set URL
All the information needed for recovery will be stored in the url type standard:
recovery = erc831_part account_contract ["@" chain_id] "/" recovery_contract "/" private_hash | secret_type "/" address_list / weight_multipler ["?" parameters] ["#" notes] erc831_part = "ethereum: recovery-" account_contract = ADDRESS chain_id = 1 * DIGIT recovery_contract = ADDRESS private_hash = "0x" 64 * HEXDIG secret_type = UINT address_list = ethereum_address * (";" ethereum_address) weight_multipler = UINT ethereum_address = ADDRESS / ENS_NAME "*" weight weight = UINT ADDRESS = "0x" 40 * HEXDIG parameters = parameter * ("&" parameter) parameter = key "=" value key = STRING value = STRING notes = STRING
account_contractrefers to the account contract to be restored. Any account contract can be used because the restoration contract can be executed to any interface or address (such as conventional multi-signature);
chain_idfor all addresses. If it does not exist, it defaults to 1 (main network);
recovery_contractexecutes the logic of the recovery contract and must support the ABI specified in this document;
secret_typeselects the standard used when generating
user_secret_data, which is required when no
private_hashis a hash of
user_secret_data. If it does not exist, recovery will require the standard selected by
secret_typeto be used to obtain
weight_multipleris the value that each
weightwill be multiplied to reach the
address_listis a list of addresses with personal weights, preferably another account contract, indicating that they can be used for recovery requests, but any address can help recovery. You can use the ENS domain name and resolve it during the recovery process. The total weight should be higher than the
Math.ceil(THRESHOLD / address_list.length)by default, which is set by the user;
parametersmay require a specific
notescan be used for password hints if needed;
When recovery is required, users need to load their
Recovery Secret Set URL into an e-wallet that supports this standard. Depending on the configuration, when
private_hash not available, it must be generated from
user_secret_data , which poses a challenge to the user.
When a valid key set is loaded, it will prompt which users ask for help. Some wallets may be able to send requests automatically, while others allow users to share this
Help Recover Request URL .
The EIP encourages the use of pre-signed messages EIP-191 whenever possible, which is important because gas cost is a common obstacle. If the address chosen by the guardian is an account contract, it must be EIP-1271 to use the pre-signed information. The suggested normal sequence is as follows:
In special cases, if the account contract cannot sign the information, or the user's wallet cannot sign the information in the format specified on this EIP, you can also use the msg.sender method to perform general operations.
In this case, the guardian will have to pay a small gas fee.
user_secret_data never made public. After hashing it once with the keccak256 algorithm, it becomes
private_hash that is never made public. In theory, biometric technology should be used because users are less likely to lose their biometrics. And biometrics are usually not secure because they are not really secrets. Most high-resolution cameras can actually read most biometrics, and this information is usually known to governments.
When biometrics are not available, the user data form still provides fairly good security, because the hash stored in the contract is a salted hash that is very far from the source data, and even if only the name is used as
user_secret_data , it is difficult found. The more unpredictable this data is, the more it can withstand targeted attacks, which still need to discover the user list and receive sufficient authorization.
It should be noted that wallets supporting this EIP should consider that users may be requested to help restore other accounts, and the request may come from anyone who knows
secret_set , including legal owners or attackers who have obtained
secret_set in some way.
- The wallet must ask the user for the legitimacy of the request, and ask whether the request was made after personal verification;
- Users must know that they are responsible for their on-chain operations (ethical and legal in some countries) and must verify the legitimacy of the recovery request;
- Video calls may be faked by AI, but the attacker needs images and voice samples, such as public speech content on the Internet;
- Users who restore for celebrities should never trust video calls and should try to contact the people around them directly to check the legitimacy of the request;
Comment: This solution is designed for groups such as Peter Schiff who easily forget the wallet password or private key, but it also has security risks, and it is very important for the social scalability of cryptocurrencies Because most people will be similar to Peter Schiff when they first encounter cryptocurrencies. This article has omitted a lot of technical details, and interested readers can read the original proposal content: https://gitlab.com/status-im/docs/EIPs/blob/secret-multisig-recovery/EIPS/eip-2429.md