From dce4a5c2cb73e1ace59e0a3340602241f95deafa Mon Sep 17 00:00:00 2001 From: ehanoc Date: Mon, 15 Apr 2024 12:55:14 +0100 Subject: [PATCH 1/6] First Draft BIP44 wallet recovery Signed-off-by: ehanoc --- ARCs/arc-0300.md | 60 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 60 insertions(+) create mode 100644 ARCs/arc-0300.md diff --git a/ARCs/arc-0300.md b/ARCs/arc-0300.md new file mode 100644 index 000000000..48c28ab55 --- /dev/null +++ b/ARCs/arc-0300.md @@ -0,0 +1,60 @@ +# ARC-0300: 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. + +## 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. + +## Proposal +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. + +## Specification + +Based on [BIP44 Account Discovery](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#user-content-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. +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, 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. + +## References +- [BIP44: Hierarchical Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) +- [Algorand Developer Documentation](https://developer.algorand.org/) \ No newline at end of file From 9654ef7844c33656e79c17f4819dfed426f2a691 Mon Sep 17 00:00:00 2001 From: ehanoc Date: Mon, 15 Apr 2024 12:59:41 +0100 Subject: [PATCH 2/6] Definitions and refinment Signed-off-by: ehanoc --- ARCs/arc-0300.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/ARCs/arc-0300.md b/ARCs/arc-0300.md index 48c28ab55..565dd493e 100644 --- a/ARCs/arc-0300.md +++ b/ARCs/arc-0300.md @@ -40,8 +40,9 @@ and where `'` denotes a hardened derivation. ### 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. +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. From edb2135532485b1a117e15f6b32c2fcea0a1c4f5 Mon Sep 17 00:00:00 2001 From: ehanoc Date: Mon, 15 Apr 2024 13:01:23 +0100 Subject: [PATCH 3/6] Header of ARC Signed-off-by: ehanoc --- ARCs/arc-0300.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/ARCs/arc-0300.md b/ARCs/arc-0300.md index 565dd493e..55aa18f87 100644 --- a/ARCs/arc-0300.md +++ b/ARCs/arc-0300.md @@ -1,3 +1,13 @@ +--- +arc: ??? +title: HDWallets recovery using BIP44 +description: How to recover Algorand wallets using BIP44 +author: Bruno Martins (@ehanoc, bruno.martins@algorand.foundation) +status: Draft +type: Standards Track +created: 2024-04-15 +--- + # ARC-0300: HDWallets recovery using BIP44 ## Abstract From ee00f88e6769013f92ce94f79f3c95cbfc2b6872 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?St=C3=A9phane?= Date: Tue, 16 Apr 2024 10:42:51 +0200 Subject: [PATCH 4/6] Naming ARC + format links --- ARCs/{arc-0300.md => arc-0061.md} | 47 ++++++++++++++++++++----------- 1 file changed, 30 insertions(+), 17 deletions(-) rename ARCs/{arc-0300.md => arc-0061.md} (77%) diff --git a/ARCs/arc-0300.md b/ARCs/arc-0061.md similarity index 77% rename from ARCs/arc-0300.md rename to ARCs/arc-0061.md index 55aa18f87..ff4e25c36 100644 --- a/ARCs/arc-0300.md +++ b/ARCs/arc-0061.md @@ -1,46 +1,51 @@ --- -arc: ??? +arc: 61 title: HDWallets recovery using BIP44 -description: How to recover Algorand wallets using BIP44 -author: Bruno Martins (@ehanoc, bruno.martins@algorand.foundation) +description: How to recover Algorand wallets using BIP44 +author: Bruno Martins (@ehanoc) status: Draft type: Standards Track +category: ARC created: 2024-04-15 --- -# ARC-0300: HDWallets recovery using BIP44 +# 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. -## 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. +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. -## Proposal 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](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#user-content-Account_discovery), we define Algorand's BIP44 path as follows: +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. +and where `'` denotes a hardened derivation. ### Definitions @@ -51,14 +56,13 @@ and where `'` denotes a hardened derivation. 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. + - 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, closing operations, etc. +Any operation recorded on the Algorand blockchain that involves the `address`. This includes all standard transactions types, asset transfers, re-keying, 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. @@ -66,6 +70,15 @@ When scanning for activity of algorand addresses, it is not sufficient to look a 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. -## References -- [BIP44: Hierarchical Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) -- [Algorand Developer Documentation](https://developer.algorand.org/) \ No newline at end of file +### References + +- BIP44: Hierarchical Deterministic Wallets +- Algorand Developer Documentation + +## Rationale + +## Security Considerations + +## Copyright + +Copyright and related rights waived via CCO. From 01b2e07730501c67bf228043bb3daf42e500ace3 Mon Sep 17 00:00:00 2001 From: ehanoc Date: Mon, 22 Apr 2024 11:15:52 +0100 Subject: [PATCH 5/6] Adding wallet recomendations Signed-off-by: ehanoc --- ARCs/arc-0061.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/ARCs/arc-0061.md b/ARCs/arc-0061.md index ff4e25c36..bc0b9cd73 100644 --- a/ARCs/arc-0061.md +++ b/ARCs/arc-0061.md @@ -70,6 +70,16 @@ When scanning for activity of algorand addresses, it is not sufficient to look a 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. + ### References - BIP44: Hierarchical Deterministic Wallets From 0d66ac250c800f9b903b506e6640f3dbb1eb397e Mon Sep 17 00:00:00 2001 From: ehanoc Date: Mon, 22 Apr 2024 11:32:22 +0100 Subject: [PATCH 6/6] Adding rekeyed addresses recomendations Signed-off-by: ehanoc --- ARCs/arc-0061.md | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/ARCs/arc-0061.md b/ARCs/arc-0061.md index bc0b9cd73..ff9659863 100644 --- a/ARCs/arc-0061.md +++ b/ARCs/arc-0061.md @@ -62,7 +62,7 @@ and where `'` denotes a hardened derivation. #### Address activity -Any operation recorded on the Algorand blockchain that involves the `address`. This includes all standard transactions types, asset transfers, re-keying, closing operations, etc. +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. @@ -80,6 +80,16 @@ The end user will likely not be familiar with the concept of BIP44 paths, so the 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