Add transparent address gap limit handling & general address rotation functionality. #1673
Conversation
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
nuttycom
force-pushed
the
feature/transparent_gap_limit_handling
branch
16 times, most recently
from
62c1394 to
bd2df86
Compare
nuttycom
changed the title
nuttycom
force-pushed
the
feature/transparent_gap_limit_handling
branch
from
bd2df86 to
4b99663
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1673 +/- ##
==========================================
- Coverage 54.17% 54.15% -0.03%
==========================================
Files 176 179 +3
Lines 20469 21175 +706
==========================================
+ Hits 11089 11467 +378
- Misses 9380 9708 +328 ☔ View full report in Codecov by Sentry. |
nuttycom
force-pushed
the
feature/transparent_gap_limit_handling
branch
2 times, most recently
from
1386dd1 to
49230de
Compare
str4d
added a commit
that referenced
this pull request
Dec 30, 2024
…handling-prep Preparatory refactoring for #1673
nuttycom
force-pushed
the
feature/transparent_gap_limit_handling
branch
2 times, most recently
from
b39c6c3 to
3ac0396
Compare
str4d
reviewed
Dec 30, 2024
str4d
reviewed
Dec 30, 2024
str4d
previously approved these changes
Feb 11, 2025
nuttycom
force-pushed
the
feature/transparent_gap_limit_handling
branch
from
eca51d6 to
813dd24
Compare
|
force-pushed to fix conflicts with |
|
Marked as draft at 813dd24 since we intend to make crate releases prior to the merge of this PR. |
nuttycom
force-pushed
the
feature/transparent_gap_limit_handling
branch
from
813dd24 to
709b9be
Compare
|
force-pushed to rebase on |
This is a large change that unifies the handling of ephemeral transparent addresses for ZIP 320 support with generalized "gap limit" handling for transparent wallet recovery. The best way to understand this commit is to start from the `transparent_gap_limit_handling` database migration that drives the change in behavior.
Co-authored-by: Jack Grigg <[email protected]>
…resses. The rationale behind this change is that current implementations of UTXO retrieval do not attempt to avoid revealing that multiple addresses belong to the same wallet when using a light wallet server to check for transparent UTXOs. A comprehensive solution to this problem requires changes to the light wallet protocol such that wallets no longer need to submit batches of addresses to the light wallet server, and can instead determine whether outputs exist for their addresses locally. By setting the default gap limit to 10 addresses, we make it possible for wallets that add privacy-preserving UTXO checking in the future (either by connecting to full node indexes directly in a privacy-preserving manner or via changes that take advantage of an updated light wallet protocol) to then start generating new addresses within a range of the industry-standard 20 address gap limit that have not yet been revealed to belong to the wallet.
In the presence of gap-limit addresses, querying for UTXOs based exclusively upon the last height at which such a query was executed is inadequate to fully recover the contents of a wallet; when a transaction is discovered in the past, this may advance the gap limit, and newly exposed addresses may receive outputs immediately following the discovered transaction. We can expect that when a transparent output belonging to the wallet is discovered, that the height at which that transaction was mined was checked in a query that included _all_ of addresses having child indices less than or equal to that of the involved address. Therefore, it's safe to start looking for addresses in the gap as of that point.
…ess exposure height.
Also, this removes the default value for the `addresses.key_scope` column, better reflecting the fact that all address insertion code needs to properly set the key scope.
nuttycom
force-pushed
the
feature/transparent_gap_limit_handling
branch
from
709b9be to
cac7d28
Compare
|
force-pushed to rebase on |
nuttycom
force-pushed
the
feature/transparent_gap_limit_handling
branch
from
8db439f to
f9fc8bb
Compare
nuttycom
force-pushed
the
feature/transparent_gap_limit_handling
branch
from
2d61c05 to
89dcdfc
Compare
|
Logical changes since last reviews (post-rebase-on-main) are here |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
No description provided.