From 1b7590e0090d4f58fe2b4a4b0d74e2bc2eee3a79 Mon Sep 17 00:00:00 2001 From: Luke Dashjr Date: Fri, 12 May 2017 04:54:53 +0000 Subject: bip-0115: Include best practices for wallets, and explain difference from lock-time in Rationale --- bip-0115.mediawiki | 12 ++++++++++++ 1 file changed, 12 insertions(+) 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 OP_CHECKBLOCKATHEIGHT) 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. OP_CHECKBLOCKATHEIGHT, 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. -- cgit v1.2.3