BIP352: Add extra encoding formats for scanning and spending #2026
Conversation
This file contains hidden or 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
5 tasks
jonatack
added
Proposed BIP modification
Pending acceptance
jonatack
reviewed
Nov 1, 2025
Member
jonatack
left a comment
jonatack
left a comment
There was a problem hiding this comment.
cc BIP authors @josibake and @RubenSomsen for feedback
nymius
reviewed
Nov 3, 2025
nymius
reviewed
Nov 4, 2025
| When scanning for payments, wallets MUST always check for label ''m = 0'' (the change label), regardless of the ''max_label'' value. This ensures compatibility across different wallet implementations and prevents loss of funds if the wallet has generated change outputs using the reserved change label. | ||
|
|
||
| Wallet implementations SHOULD include all labels that have been distributed or used when exporting the wallet key material. However, wallets recovering from an ''spscan'' or ''spspend'' encoding SHOULD be prepared to scan for additional labels beyond those included in the encoding, as users may have shared additional labeled addresses. | ||
| When a ''max_label'' value is present in the encoding, wallets MUST scan for all labels in the range [0, ''max_label''], inclusive. This design encourages users to use a dense range of labels (e.g., 1, 2, 3, 4, 5) rather than sparse labels (e.g., 1, 100, 1000), resulting in more efficient scanning and a fixed-size encoding. |
Contributor
There was a problem hiding this comment.
I wouldn't say the scanning is more efficient with a dense range, what is more efficient is the backup of the label information.
For scanning on fully fledged scanners, the use of any number of labels is as performant as the use of no labels.
For light clients the cost of checking N labels is equal to N times the use of no labels. Additionally, the bandwidth consumption is also equal to N times the use of no labels.
Contributor
There was a problem hiding this comment.
To clarify my original point, the reason I would do it like this is to produce a shorter, fixed size encoding and have a compact backup format.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
Based on a discussion I started on Delving Bitcoin
Also related: BTC Transcripts
BIP authors:
@josibake @RubenSomsen
These two new encodings are a way for Silent Payment users to:
I was debating whether to make the non-address encodings into descriptors instead. But that would be an easy change to make.
Just creating this PR so that specific discussions about wording can take place.
Thanks.