From 3fd971455a3fc3a49ca47ec7fdec58c358da33dd Mon Sep 17 00:00:00 2001 From: Salvatore Ingala <6681844+bigspider@users.noreply.github.com> Date: Wed, 10 Jul 2024 17:58:48 +0200 Subject: Add paragraph on key reuse --- bip-0388.mediawiki | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/bip-0388.mediawiki b/bip-0388.mediawiki index dc1b508..1fd6994 100644 --- a/bip-0388.mediawiki +++ b/bip-0388.mediawiki @@ -42,7 +42,7 @@ A more native, compact representation of the wallet receive and change addresses We remark that wallet policies are not related to the ''policy'' language, a higher level language that can be compiled to miniscript. -=== Security and UX concerns for hardware signing devices === +=== Security, privacy and UX concerns for hardware signing devices === The usage of complex scripts presents challenges in terms of both security and user experience for a hardware signing device. @@ -57,6 +57,18 @@ The hardware signing device must guarantee that the user knows precisely what "p This makes it impossible for an attacker to surreptitiously modify the policy, therefore stealing or burning the user's funds. +==== Avoiding key reuse ==== + +Reusing public keys within a Script is a source of malleability when using miniscript policies, which has potential security implications. + +Reusing keys across different UTXOs harms user privacy by allowing external parties to link these UTXOs to the same entity once they are spent. + +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 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. + ==== UX issues ==== Miniscript (and taproot trees) allow substantially more complex spending policies. It is a challenge to ensure that the user can practically verify such spending policies per the screen. @@ -189,8 +201,6 @@ Implementations can add additional metadata that is stored together with the wal Any implementation in a software wallet that allows wallet policies not matching any of the specifications in [[bip-0044.mediawiki|BIP-44]], [[bip-0049.mediawiki|BIP-49]], [[bip-0084.mediawiki|BIP-84]], [[bip-0086.mediawiki|BIP-86]] (especially if involving external cosigners) should put great care into a process for backing up the wallet policy that represents the account. In fact, unlike standard single-signature scenarios, the seed alone is no longer enough to discover wallet policies with existing funds, and the loss of the backup is likely to lead to permanent loss of funds. Unlike the seed, leaking such backups only affects the privacy of the user, but it does not allow the attacker to steal funds. -Avoiding key reuse among different wallet accounts is also extremely important, but out of scope for this document. - === Optional derivation paths === In order to allow supporting legacy derivation schemes (for example, using simply /* instead of the more common //* scheme most software wallets use today), or other schemes that are not covered in this document, implementations might choose to permit additional derivation patterns for the key placeholder (KP) expressions. -- cgit v1.2.3 From 8c2f54d33beb3318f42032715bac5df7f0d61149 Mon Sep 17 00:00:00 2001 From: Salvatore Ingala <6681844+bigspider@users.noreply.github.com> Date: Thu, 11 Jul 2024 10:31:01 +0200 Subject: Add references to the miniscript BIP-379 --- bip-0388.mediawiki | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/bip-0388.mediawiki b/bip-0388.mediawiki index 1fd6994..b417ac4 100644 --- a/bip-0388.mediawiki +++ b/bip-0388.mediawiki @@ -40,7 +40,7 @@ Moreover, other limitations like the limited size of the screen might affect wha A more native, compact representation of the wallet receive and change addresses might also benefit the UX of software wallets when they use descriptors (possibly with miniscript) for representing complex locking conditions. -We remark that wallet policies are not related to the ''policy'' language, a higher level language that can be compiled to miniscript. +We remark that wallet policies are not related to the ''policy'' language, a higher level language that can be compiled to [[bip-0379.md|miniscript]]. === Security, privacy and UX concerns for hardware signing devices === @@ -137,6 +137,8 @@ A ''wallet descriptor template'' is a SCRIPT expression. * tr(KP) or tr(KP,TREE) (top level only): P2TR output with the specified key as internal key, and optionally a tree of script paths. * any valid miniscript template (inside wsh or tr only). +See [[bip-0379.md|BIP-379]] for a precise specification of all the valid miniscript SCRIPT expressions. + TREE expressions: * any SCRIPT expression * An open brace {, a TREE expression, a comma ,, a TREE expression, and a closing brace } -- cgit v1.2.3 From 0adf7c36e1796653d2bdf778ff6f241455fbf85d Mon Sep 17 00:00:00 2001 From: Salvatore Ingala <6681844+bigspider@users.noreply.github.com> Date: Thu, 11 Jul 2024 10:33:13 +0200 Subject: Nit: it's not 'two' descriptors if one uses the multipath expressions per BIP-389 --- bip-0388.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0388.mediawiki b/bip-0388.mediawiki index b417ac4..225ce7a 100644 --- a/bip-0388.mediawiki +++ b/bip-0388.mediawiki @@ -14,7 +14,7 @@ == 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 exactly two descriptors, which produce the receive and change addresses that are logically part of the same account. +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. 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. -- cgit v1.2.3 From 0b3c79c257067dabadb34829fa616534a54f23af Mon Sep 17 00:00:00 2001 From: Salvatore Ingala <6681844+bigspider@users.noreply.github.com> Date: Wed, 17 Jul 2024 10:18:53 +0200 Subject: Apply suggestions from code review Co-authored-by: Mark "Murch" Erhardt --- bip-0388.mediawiki | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/bip-0388.mediawiki b/bip-0388.mediawiki index 225ce7a..fd28f04 100644 --- a/bip-0388.mediawiki +++ b/bip-0388.mediawiki @@ -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. -- cgit v1.2.3 From c2655e0ab988ea2a43264186a368b7b4ec3734f9 Mon Sep 17 00:00:00 2001 From: Salvatore Ingala <6681844+bigspider@users.noreply.github.com> Date: Sat, 27 Jul 2024 19:36:08 +0200 Subject: More adjustments from PR review --- bip-0388.mediawiki | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/bip-0388.mediawiki b/bip-0388.mediawiki index fd28f04..7f0aab5 100644 --- a/bip-0388.mediawiki +++ b/bip-0388.mediawiki @@ -14,7 +14,8 @@ == Abstract == -Software wallets and hardware signing devices sequester wallet uses into logically separate "accounts". +Software wallets and hardware signing devices typically partition funds into separate "accounts". When signing or visualizing transactions, this allows to show to the user aggregate in-flow or out-flow information for one or more involved 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. @@ -67,7 +68,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. -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 strongly recommended to avoid key reuse across accounts. Distinct public keys per account can be guaranteed by using distinct hardened derivation paths. This specification does not mandate hardened derivation in order 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. -- cgit v1.2.3 From 00fbea5dcd5e90449f270a046ac3fcfdea100b65 Mon Sep 17 00:00:00 2001 From: Salvatore Ingala <6681844+bigspider@users.noreply.github.com> Date: Sat, 3 Aug 2024 17:05:46 +0200 Subject: Nit from PR review Co-authored-by: Mark "Murch" Erhardt --- bip-0388.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0388.mediawiki b/bip-0388.mediawiki index 7f0aab5..6524441 100644 --- a/bip-0388.mediawiki +++ b/bip-0388.mediawiki @@ -62,7 +62,7 @@ This makes it impossible for an attacker to surreptitiously modify the policy, t ==== Avoiding key reuse ==== -Reusing public keys within a Script is a source of malleability when using miniscript policies, which has potential security implications. +Reusing public keys within a script is a source of malleability when using miniscript policies, which has potential security implications. Reusing keys across different UTXOs harms user privacy by allowing external parties to link these UTXOs to the same entity once they are spent. -- cgit v1.2.3 From 1811613e07f878a42ebeb57e714cdc93664082d3 Mon Sep 17 00:00:00 2001 From: Salvatore Ingala <6681844+bigspider@users.noreply.github.com> Date: Wed, 14 Aug 2024 15:07:55 +0200 Subject: Further improvements from PR review --- bip-0388.mediawiki | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/bip-0388.mediawiki b/bip-0388.mediawiki index 6524441..895e5a0 100644 --- a/bip-0388.mediawiki +++ b/bip-0388.mediawiki @@ -14,7 +14,7 @@ == Abstract == -Software wallets and hardware signing devices typically partition funds into separate "accounts". When signing or visualizing transactions, this allows to show to the user aggregate in-flow or out-flow information for one or more involved accounts. +Software wallets and hardware signing devices typically partition funds into separate "accounts". When signing or visualizing a transaction, aggregate flows of funds of all accounts affected by the transaction may (and should) be displayed to the user. 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. @@ -70,7 +70,7 @@ By constraining the derivation path patterns to have a uniform structure, wallet It is strongly recommended to avoid key reuse across accounts. Distinct public keys per account can be guaranteed by using distinct hardened derivation paths. This specification does not mandate hardened derivation in order 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. +It is out of scope for this document to guarantee that users do not reuse extended public keys among different wallet accounts. This is still very important, but the responsibility is left to the users and their software wallet. ==== UX issues ==== -- cgit v1.2.3