BIP352: Add extra encoding formats for scanning and spending#2026
BIP352: Add extra encoding formats for scanning and spending#2026junderw wants to merge 2 commits intobitcoin:masterfrom
Conversation
jonatack
left a comment
There was a problem hiding this comment.
cc BIP authors @josibake and @RubenSomsen for feedback
| 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. |
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.
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.
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.
I agree with that. The number of labels is relevant not their m number.
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.