diff options
| -rw-r--r-- | bip-0115.mediawiki | 12 |
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. |