1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-03-04 11:08:05 +01:00

Apply suggestions from code review

Co-authored-by: Mark "Murch" Erhardt <murch@murch.one>
This commit is contained in:
Salvatore Ingala 2024-05-05 11:38:49 -05:00
parent 25657cbee6
commit 40c7760d78
No known key found for this signature in database
GPG key ID: 74060FF81B33E4F8

View file

@ -9,6 +9,7 @@
Type: Standards Track Type: Standards Track
Created: 2022-11-16 Created: 2022-11-16
License: BSD-2-Clause License: BSD-2-Clause
Post-History: 2022-05-10: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020423.html
</pre> </pre>
== Abstract == == Abstract ==
@ -64,7 +65,7 @@ Therefore, there are two fundamental design goals to strive for:
* Minimize the amount of information that is shown on screen - so that the user can actually validate it. * Minimize the amount of information that is shown on screen - so that the user can actually validate it.
* Minimize the number of times the user has to validate such information. * Minimize the number of times the user has to validate such information.
Designing a secure protocol for the coordination of a descriptor wallet among distant parties is also a challenging problem that is out of scope in this document. See [[bip-00129.mediawiki|BIP-129 (Bitcoin Secure Multisig Setup)]] for an approach designed for multisignature wallets. Regardless the approach, the ability for the user to carefully verify all the details of the spending policies using the hardware signer's screen is a prerequisite for security in adversarial environments. Designing a secure protocol for the coordination of a descriptor wallet among distant parties is also a challenging problem that is out of scope in this document. See [[bip-00129.mediawiki|BIP-129 (Bitcoin Secure Multisig Setup)]] for an approach designed for multisignature wallets. Regardless of the approach, the ability for the user to carefully verify all the details of the spending policies using the hardware signer's screen is a prerequisite for security in adversarial environments.
=== Policy registration as a solution === === Policy registration as a solution ===
@ -320,7 +321,7 @@ Remark: some of the descriptor templates above might be valid if optional extens
The <tt>@</tt> character used for key placeholders is not part of the syntax of output script descriptors, therefore any valid output descriptor with at least one `KEY` expression is not a valid descriptor template. Vice versa, any descriptor template with at least one key placeholder is not a valid output script descriptor. The <tt>@</tt> character used for key placeholders is not part of the syntax of output script descriptors, therefore any valid output descriptor with at least one `KEY` expression is not a valid descriptor template. Vice versa, any descriptor template with at least one key placeholder is not a valid output script descriptor.
Adoption of wallet policies in software and harder wallets is opt-in. Conversion from wallet policies to the corresponding descriptors is programmatically extremely easy, and conversion from descriptors to wallet policies (when respecting the required patterns) can be automated. See the reference implementation below for some examples of conversion. Adoption of wallet policies in software and hardware wallets is opt-in. Conversion from wallet policies to the corresponding descriptors is programmatically extremely easy, and conversion from descriptors to wallet policies (when respecting the required patterns) can be automated. See the reference implementation below for some examples of conversion.
Software wallets are recommended to allow exporting plain descriptors for the purposes of interoperability with software not using wallet policies. Software wallets are recommended to allow exporting plain descriptors for the purposes of interoperability with software not using wallet policies.