Skip to content
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
wants to merge 6 commits into
base: main
Choose a base branch
from
Open
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
71 changes: 71 additions & 0 deletions ARCs/arc-0300.md
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, bruno.martins@algorand.foundation)
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.
Copy link
Contributor

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.

  1. 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 to account[19]. Do we expect the wallet to find this? If so, should that count as activity for account[19]?

  2. 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.

  3. 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.

Copy link
Contributor

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.

If no **activity** is found on the first scan of the account, stop scanning.

Copy link
Author

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

  1. 👍

  2. 👍

Copy link
Author

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.

If no **activity** is found on the first scan of the account, stop scanning.

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

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/)
Loading