1
0
mirror of https://github.com/bitcoin/bips.git synced 2025-01-18 13:26:08 +01:00

Apply suggestions from code review

Co-authored-by: Mark "Murch" Erhardt <murch@murch.one>
This commit is contained in:
Salvatore Ingala 2024-07-17 10:18:53 +02:00 committed by GitHub
parent 0adf7c36e1
commit 0b3c79c257
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194

View File

@ -14,7 +14,9 @@
== Abstract ==
Wallet policies build on top of output script descriptors to represent the types of descriptors that are typically used to represent "accounts" in a software wallet, or a hardware signing device, in a compact, reviewable way. A wallet policy always represents descriptors which produce all the receive and change addresses that are logically part of the same account.
Software wallets and hardware signing devices sequester wallet uses into logically separate "accounts".
Wallet policies build on top of output script descriptors to represent such accounts in a compact, reviewable way.
An account encompasses a logical group of receive and change addresses, and each wallet policy represents all descriptors necessary to describe an account in its entirety.
We simplify the language to suit devices with limited memory, where even keeping the entire descriptor in memory could be a major hurdle, by reducing the generality of descriptors to just the essential features and by separating the extended pubkeys and other key information from the descriptor.
@ -65,7 +67,7 @@ Reusing keys across different UTXOs harms user privacy by allowing external part
By constraining the derivation path patterns to have a uniform structure, wallet policies prevent key reuse among the same or different UTXOs of the same account.
Using distinct public keys obtained from hardened derivation paths guarantees that no key reuse can happen also across accounts, and is strongly recommended. However, wallet policies do not mandate hardened derivation paths for the public keys, in order to maintain compatibility with existing deployments that do not adhere to this recommendation.
It is strongly recommended to avoid key reuse across accounts. Distinct public keys per account can be guaranteed per hardened derivation paths. This specification does not mandate hardened derivation to maintain compatibility with existing deployments that do not adhere to this recommendation.
It is out of scope for this document to guarantee that users do not reuse extended public keys among different wallet accounts. This responsibility is left to the users and their software wallet.