Add paragraph on key reuse

Author: bigspider

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 <tt>/*</tt> instead of the more common <tt>/<M;N>/*</tt> 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 (<tt>KP</tt>) expressions.