Published on: 2017-08-09T20:14:18+00:00
Colin has proposed a structure for trustless use of hybrid wallets, allowing for emergency recovery of funds in case of a lost wallet. The transaction script involves the user signing a transaction with their userWalletPrivKey and authenticating with the server, which then signs with their serverWalletPrivKey. If the server goes rogue and refuses to sign, the user can use their userRecoveryPrivKey to send the funds anywhere they choose. In case the user forgets their password and loses access to their userWalletPrivKey and recovery key, they can rely on the serverRecoveryPrivKey.During wallet setup, users provide basic identity information and set up a recovery password or answer recovery questions. None of this information is sent to the server except for the 256-bit hash used to identify the recovery wallet. The server creates a 1025-bit nonce, encrypts it, stores it, and transmits it to the user's client along with the server's recovery private key. The client uses SHA512 on the combination of identity questions and answers, recovery password (if used), recovery questions and answers, and the nonce. It encrypts the serverRecoveryPrivKey using the resulting hash, which is then encrypted again for transmission to the server.In the event that the user needs to resort to using the recovery option, they use their information to build their recovery identifier. The server may request e-mail and/or SMS confirmation before proceeding. The server decrypts the saved nonce and the first layer of encryption on the serverRecoveryPrivKey, then encrypts both for transmission to the user's client. The client removes the transmission encryption and calculates the 512-bit hash used to originally encrypt the serverRecoveryPrivKey. Finally, the user can decrypt the airbitzServerRecoveryPrivKey and use it to send a transaction to any chosen destination.Nick has provided feedback on Colin's proposal, suggesting that the key used to encrypt the nonce by the server should be included and questioning the effectiveness of the recovery questions asked. Nick also raises concerns about potential mitigations to prevent the server from stealing the wallet using a dictionary of common pet names.The userRecoveryPrivKey can be used to send funds if the server stops signing, and it is recommended to store it in cold wallet storage for security reasons. The userWalletPubKey, on the other hand, is a hot key stored on the user's computer, typically in a browser-based local storage container. If there is an attack on the serverWalletPubKey, which stores the user's personal information, including xpub, this increases the user's risk compared to cold or HWW keys.The proposed structure aims to allow trustless use of hybrid wallets without having to fully trust them. The TX script running this structure involves the use of "IF 1 2 CHECKMULTISIGVERIFY ELSE 2 2 CHECKMULTISIG ENDIF". In case of a lost wallet, recovery of funds can be done using the userRecoveryPrivKey. Authentication with the server can be done using two-factor authentication (2FA) methods like Authy or Google Authenticator. The author suggests that this structure could make a good informational BIP (Bitcoin Improvement Proposal).
Updated on: 2023-08-01T21:25:44.425124+00:00