-
Notifications
You must be signed in to change notification settings - Fork 13
fix:adjust default paths and gap limits to match android/iOS behavior #156
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
Changes from 8 commits
9f845aa
0f0978e
cc8d49c
bbf43a9
971be53
7fc5df7
430da5b
3cdd496
7bec305
a282394
c65c6e1
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -11,14 +11,16 @@ use serde::{Deserialize, Serialize}; | |
| use std::collections::HashSet; | ||
|
|
||
| /// Standard gap limit for external addresses (BIP44 recommendation) | ||
| pub const DEFAULT_EXTERNAL_GAP_LIMIT: u32 = 20; | ||
| pub const DEFAULT_EXTERNAL_GAP_LIMIT: u32 = 100; | ||
|
|
||
| /// Standard gap limit for internal (change) addresses | ||
| pub const DEFAULT_INTERNAL_GAP_LIMIT: u32 = 10; | ||
| pub const DEFAULT_INTERNAL_GAP_LIMIT: u32 = 100; | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There is no point in having 100 here, it would mean we skipped 99 internal addresses. I'm not even sure how you can miss 1.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I guess we should have it at 25, because that's how many transactions you can have in a block from one ancestor. But honestly with some good coding we could have this at 5.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I agree, internal can be less because the addresses are generated by the app when spending and not by the user.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Using the test wallet that was created with iOS, 30 external and 30 internal gap limits resulted in successful restoration. In this particular wallet, 20 internal was not sufficient. |
||
|
|
||
| /// Standard gap limit for CoinJoin addresses | ||
| pub const DEFAULT_COINJOIN_GAP_LIMIT: u32 = 10; | ||
| pub const DEFAULT_COINJOIN_GAP_LIMIT: u32 = 500; | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I really don't think we need more than 30 here.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We had problems with lower numbers, previously, but some of those problems were due not updating the bloom filters often enough. With coinjoin, on Android, we support up to 6 active sessions and each session could be using up to 9 keys. That means 54 keys could be used at a time. The number can be lower than 500 -- I can do testing to see what would work based on some of my wallets.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Using a different test wallet which has 4300 transactions, mostly coinjoin, I found that a gap limit of 30 is sufficient. The number of keys used in those 4300 transactions was 12068. With the DashJ library, there is an algorithm that searches for unused keys and reuses them. Unused keys would be from failed mixing sessions where some keys were allocated, but not used due to a timeout or disconnection. |
||
|
|
||
| /// Standard gap limit for special purpose keys (identity, provider keys) | ||
| pub const DEFAULT_SPECIAL_GAP_LIMIT: u32 = 20; | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We should probably have this less.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The benefit to having high gap limits is significantly lower with bip157/158 compared to bloom filters.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Agreed, these could be 5. |
||
| /// Maximum gap limit to prevent excessive address generation | ||
| pub const MAX_GAP_LIMIT: u32 = 1000; | ||
|
|
||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -306,9 +306,9 @@ fn test_transaction_affects_multiple_accounts() { | |
| }; | ||
| wallet.add_account(account_type, network, None).expect("Failed to add account to wallet"); | ||
|
|
||
| // Add a BIP32 account | ||
| // Add another BIP32 account | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. the first one was BIP44
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. To maintain compatibility with old wallets, BIP32 was added to Default. That is why these tests were updated. However, if we wanted Default to not have BIP32 (for new wallets), but have a another enum item that does contain BIP32 for restoring a wallet (as in the test wallet we are using), then this test could be returned to its original code. And I could add a |
||
| let account_type = AccountType::Standard { | ||
| index: 0, | ||
| index: 1, | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. okay, but I don't think this matters.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It matters because the Default wallet already contains a BIP32 account 0, based on my changes. See above comment. |
||
| standard_account_type: StandardAccountType::BIP32Account, | ||
| }; | ||
| wallet.add_account(account_type, network, None).expect("Failed to add account to wallet"); | ||
|
|
||
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.
This would represent a significant additional computation, and I'm not sure the benefit. I Think iOS used to use 30.
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 believe GC filters are checked sequentially as well... so the added benefit we got with bloom filters no longer applies.
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 think he said that android uses 100; and so to confirm compatibility; and to get correct balances in the mobile test wallet we needed to increase. It's possible 30 work would work; @HashEngineering please advise.
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.
Let me check 30 and also look up what is in DashSync.
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.
DashSync: https://github.com/dashpay/dashsync-iOS/blob/753f9446cfd20ae5da996104a5870df839005d4c/DashSync/shared/Models/Derivation%20Paths/DSFundsDerivationPath.h#L10-L21
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.
Using the test wallet that was created with iOS, 30 external and 30 internal gap limits resulted in successful restoration. In this particular wallet, 20 internal was not sufficient.