diff --git a/bsip-1203.md b/bsip-1203.md
index 90b7ab9..dadad4e 100644
--- a/bsip-1203.md
+++ b/bsip-1203.md
@@ -85,6 +85,18 @@ XXXXX
 
 (Discuss also possible optimizations such as batching historical commitment and spend data into ranges of fixed size (say intervals of 2^17 blocks, representing a little over four days) so that these data-balls can be cached and returned efficiently without the node needing to satisfy a unique query every time.)
 
+### Pitfalls and Cautions
+
+#### An attack on address key from leak of a transaction private key
+
+A confidential output will have associated with it an "Output PubKey." He who can provide a signature from that PubKey is authorized to spend the commitment.  Automated detection of inbound commitments depends on the deterministic computation of an offset between the One-time PubKey and the Address PubKey, which is computed from the shared secret between the sender and receiver.  Because only the offset is deterministic, the sender cannot compute the private key to the Output PubKey.  Only the receiver can do this (by knowing both the offset and the Address private key).
+
+Because Output PubKeys are only used once, wallet software designers may be led to believe that the security of the Output PrivKeys are only important up until the commitment is spent.  (What would it matter, to leak that private key, when the commitment it authorizes is no longer spendable?)  This would be a mistake, however, because anyone who can compute the additive offset can subtract it from the Output PrivKey to reveal the Address PrivKey.  Although the general public is not expected to be privy to that offset, the _sender_ of the output is in posession of the offset (and the ability to compute it due to knowing the random _k_ behind the One-time PubKey).  This means the sender can compute the Address PrivKey, in the event that the recipient leaks the Output PrivKey.
+
+Thus, wallet designers should be advised to treat the Output PrivKeys handled by their wallets with at least as much care as the Address PrivKeys, even long after the commitments they authorize have been spent.  A leak of a single commitment's PrivKey is tantamount to a leak of the PrivKey for the entire wallet.
+
+(A similar risk of revealing a parent PrivKey from leak of a child PrivKey and parent XPUB when using non-hardened derivation is noted in the Bitcoin BIP-32 protocol for Hierarchical Deterministic Wallets.) 
+
 ## Discussion
 ## Summary for Shareholders
 ## Copyright