BIP-138 widens its recipient set to every distinct key in the backup payload
Victoria Shinder1 min readPull request 2300 has been merged into the BIPs repository, revising the recipient definition in BIP-138, the proposed backup scheme for wallet accounts. The specification previously drew its key set from the public keys in the descriptor or wallet policy. It now draws from the distinct public keys across all descriptor and policy sets and all content items in the payload, still in increasing lexicographical order.
BIP-138's design discussion sits on Delving Bitcoin and the bitcoindev list, and the scheme is defined in terms of a bitwise XOR over that ordered key set.
What it means
This reads as a housekeeping edit and is closer to a scoping decision. A backup payload is not one descriptor; it can carry several policy sets and a number of content items, and the earlier wording left open whose keys govern the result when a payload contains more than one of those. Taking every distinct key across the whole payload answers that unambiguously, and the word distinct is the load-bearing one — a key appearing in two policies must contribute once, or two wallets with overlapping keys would derive differently from the same material.
The practical consequence is for anyone who has already built against the draft. A change to which keys enter the ordered set changes the derived output, which means backups produced under the old reading will not reproduce under the new one. That is entirely normal for a BIP still in discussion, and it is precisely the reason to treat a draft-stage backup format as a format to test against rather than a format to store real recovery material in.