bip-0115: Include best practices for wallets, and explain difference from lock-time in Rationale

1 files changed, 12 insertions, 0 deletions

diff --git a/bip-0115.mediawiki b/bip-0115.mediawiki
index f4c8777..52366ab 100644
--- a/bip-0115.mediawiki
+++ b/bip-0115.mediawiki
@@ -62,8 +62,20 @@ In the event of a persistent blockchain split, some mechanism is desired by whic
 
 This can be guaranteed by choosing a block which exists only on either side of the split, and pinning (using <code>OP_CHECKBLOCKATHEIGHT</code>) common UTXOs to be spent only on chains based on that block.
 
+==Best practices for wallets==
+
+To avoid unnecessary conflicts when a chain is reorganized, wallets should always avoid specifying the last 100 blocks when practical.
+Wallets that use recent blocks when unavoidable SHOULD actively monitor the network and re-create transactions that are reorganised out with updated block hashes.
+Unless it conflicts with local/user security policies, wallets SHOULD retain the private key in memory to re-sign such transactions until the pinned block is at least 100 blocks deep into the chain.
+
+For ordinary usage, wallets SHOULD specify the ParamBlockHash as 16 bytes.
+
 ==Rationale==
 
+How is this different from the transaction's lock-time?
+
+* The lock-time specifies a time or block height before a transaction becomes valid. <code>OP_CHECKBLOCKATHEIGHT</code>, on the other hand, specifies a specific block's hash.
+
 Why are block heights required to be absolute, rather than relative?
 
 * A relative block height would allow for creation of transactions which are valid at block N, but not N+1. This is carefully avoided by Bitcoin to ensure that if any given block is reorganised out, non-malicious transactions can be simply re-confirmed in a later block.