diff --git a/ARCs/arc-0061.md b/ARCs/arc-0061.md new file mode 100644 index 000000000..ff9659863 --- /dev/null +++ b/ARCs/arc-0061.md @@ -0,0 +1,104 @@ +--- +arc: 61 +title: HDWallets recovery using BIP44 +description: How to recover Algorand wallets using BIP44 +author: Bruno Martins (@ehanoc) +status: Draft +type: Standards Track +category: ARC +created: 2024-04-15 +--- + +# HDWallets recovery using BIP44 + +## Abstract + +This ARC proposes the adoption of the BIP44 recovery algorithm for Algorand HDWallets, taking into consideration Algorand's specific use cases such as re-keyed accounts and closed accounts. The BIP44 recovery algorithm provides a standardized approach for deterministic key generation and account recovery, which can enhance the security and usability of Algorand wallets. + +The proposal suggests implementing the BIP44 recovery algorithm for Algorand wallets, with the following considerations: + +### Re-keyed Accounts + +Algorand supports re-keying of accounts, allowing users to change the signing key associated with their accounts. The BIP44 recovery algorithm should be extended to handle re-keyed accounts, ensuring that the recovered accounts reflect the latest signing key. + +### Closed Accounts + +Algorand also supports closing accounts, which means that an account can be closed and no longer being present in the ledger state. The algorithm should consider closed accounts that have been used in the past as part of the scanning process for account recovery. + +## Motivation + +By adopting the BIP44 recovery algorithm, Algorand can provide its users with a reliable and standardized mechanism for account recovery. The BIP44 recovery algorithm is widely used in the cryptocurrency space and has been proven to be effective in ensuring the security and recoverability of user accounts. By adopting this algorithm, Algorand can align itself with industry best practices and provide its users with a seamless and secure account recovery experience. + +## Specification + +Based on BIP44 Account Discovery, we define Algorand's BIP44 path as follows: + +``` +m / purpose' / coin_type' / account' / change / address_index +``` + +Where: + +- `purpose` is a constant set to `44'` (or `0x8000002C`). +- `coin_type` is a constant set to `283'` (or `0x8000011B`). +- `account` is the account index (0-based). +- `change` is a constant set to `0` for external addresses and `1` for internal addresses. +- `address_index` is the address index (0-based). + +and where `'` denotes a hardened derivation. + +### Definitions + +- `address`: Is the 58 characters, base32 encoded representation of an public key. +- `account`: Is the index of the account in the BIP44 path. + +### Account Discovery + +1. Starting with `account` index 0 +2. Scan until no **activity** is found for `gap_limit` consecutive addresses. + - If no **activity** is found on the first scan of the account, stop scanning. + - If addresses have been found to been re-keyed, the wallet should maintain a map of the found address and the corresponding new address / public which is not expected to sign transactions. +3. Increment `account` index by 1 and repeat the process. + +#### Address activity + +Any operation recorded on the Algorand blockchain that involves the `address`. This includes all standard transactions types, asset transfers, re-keying (to & from), closing operations, etc. + +When scanning for activity of algorand addresses, it is not sufficient to look at the latest state of the ledger since addresses can be closed and might have been used in the past. + +#### Gap Limit + +For scanning, a `gap_limit` of 20 addresses is recommended. This means that the algorithm will stop scanning an account if no activity is found for 20 consecutive addresses. + +### Wallet Recommendations + +#### New Addresses & Accounts + +The end user will likely not be familiar with the concept of BIP44 paths, so the wallet should offer generating new addresses in a user-friendly way without exposing the BIP44 path. + +#### Terms + +The wallets should differentiate between the terms `account` and `address` to avoid confusion. The term `account` should refer to the BIP44 account index, while the term `address` should refer to the base32 encoded public key. + +#### Re-keyed Algorand accounts + +While scanning to recover accounts and discovering re-keyed addresses, the wallet handle them in the following way: + +1. If the current address is the target of a re-key operation, the wallet should maintain a map of the source address and the found address. + +2. If the current address is the source of a re-key operation, the wallet should maintain a map of the source address and the new address. If the target address is not part of the current wallet or ever found in the recovery process, the wallet should inform the user. + - Wallets might offer a way to manually import the source address / account to the wallet. + + +### References + +- BIP44: Hierarchical Deterministic Wallets +- Algorand Developer Documentation + +## Rationale + +## Security Considerations + +## Copyright + +Copyright and related rights waived via CCO.