-
Notifications
You must be signed in to change notification settings - Fork 118
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ARC-61 - BIP44 Algorand wallet recovery #294
Open
ehanoc
wants to merge
6
commits into
algorandfoundation:main
Choose a base branch
from
ehanoc:algo_bip44
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from 3 commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
dce4a5c
First Draft BIP44 wallet recovery
ehanoc 9654ef7
Definitions and refinment
ehanoc edb2135
Header of ARC
ehanoc ee00f88
Naming ARC + format links
SudoWeezy 01b2e07
Adding wallet recomendations
ehanoc 0d66ac2
Adding rekeyed addresses recomendations
ehanoc File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,71 @@ | ||
--- | ||
arc: ??? | ||
title: HDWallets recovery using BIP44 | ||
description: How to recover Algorand wallets using BIP44 | ||
author: Bruno Martins (@ehanoc, [email protected]) | ||
status: Draft | ||
type: Standards Track | ||
created: 2024-04-15 | ||
--- | ||
|
||
# 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. | ||
- 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. | ||
|
||
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/) |
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should clarify addresses that have been rekeyed to an account address vs account addresses that have been rekeyed. There are three main scenarios.
An external address is rekeyed to an account address within the search. For example,
account[19]
address has no activity, but there IS an Algorand address rekeyed toaccount[19]
. Do we expect the wallet to find this? If so, should that count as activity foraccount[19]
?An account address is rekeyed to another account address. In this scenario the wallet should just keep a mapping internally and note the auth addr to the user.
An account address is rekeyed to an external address. In this case the wallet should inform the user that the address is rekeyed, but still count it as activity.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm with Joe here, this second bullet point needs some clarification.
Small nitpick: the following bullet point talks only about the first scan, not the 2nd, 3rd, etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great points @joe-p , will add these cases.
So for 1) It would consider that an address has activity
👍
👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't follow @k13n , there's only 1 overall scan. You "scan" until the first 20 addresses (gap_limit) of an account (bip44 account, no Algorand "account") have no activity. Otherwise you keep moving to the next account