bwt
bwt copied to clipboard
bwt-dev
Deal with descriptor checksum collisions
Collisions are highly unlikely for typical bwt usage, but might become an issue in setups where there are many dynamically-managed xpubs, for example if each customer is given its own xpub for deposits.
This could be resolved by using the full 160 bit identifier, or possibly by using the descriptor checksums as the primary identifier instead of the bip32 fingerprint (once descriptor-based tracking is implemented, #1 / #37).
Related stack exchange questions:
- Why was the bip32 fingerprint used for bip174 psbt?
- What does “deal with collisions” mean in the context of BIP32 fingerprints?
Following the descriptor support added in #1, bwt now uses descriptor checksums as the wallet identifier. This gives us 40 bits compared to 32 bits with bip32 fingerprints, which is somewhat better but still potentially prune to collisions.
For now, I added a check for collisions in the provided descriptors and made bwt refuse to start up if it detects any. A more ideal solution would be to let users specify their own wallet identifiers, or replacing descriptor checksums with some custom hash-based identifier that uses more bits. (Although, checksums do have the advantage of being a standard understood by other software.)