From 28621f70b53597ac7eab3e1f4a032a73019a6847 Mon Sep 17 00:00:00 2001 From: Luke Dashjr Date: Fri, 12 May 2017 04:08:40 +0000 Subject: bip-noreplay: Explain same-block and recent-block cases --- bip-noreplay.mediawiki | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) (limited to 'bip-noreplay.mediawiki') diff --git a/bip-noreplay.mediawiki b/bip-noreplay.mediawiki index 83680e3..e5b725f 100644 --- a/bip-noreplay.mediawiki +++ b/bip-noreplay.mediawiki @@ -28,7 +28,7 @@ When this opcode is executed: * If the stack has fewer than 2 elements, the script fails. * If the top item on the stack cannot be interpreted as a minimal-length 32-bit CScriptNum, the script fails. * The top item on the stack is interpreted as a block height (ParamHeight). -* If the blockchain (in the context of the execution) does not have ParamHeight blocks, the script fails (this failure must not be cached across blocks; it is equivalent to non-final status). +* If the blockchain (in the context of the execution) does not have ParamHeight blocks prior to the one including this transaction, the script fails (this failure must not be cached across blocks; it is equivalent to non-final status). * If ParamHeight specifies a block deeper than 52596 blocks in the chain (including negative values), the opcode completes successfully and script continues as normal. * The second-to-top item on the stack is interpreted as a block hash (ParamBlockHash). * If ParamBlockHash is longer than 28 bytes, the script fails. @@ -88,7 +88,10 @@ What if ParamBlockHash has leading zeros? Should this be prevented? * It is unlikely that the leading zeros will ever be necessary for sufficient precision, so the additional space is not a concern. * Since all block hashes are in principle shorter than than 29 bytes, ParamBlockHash may not be larger than 28 bytes. -TODO +Why is it safe to allow checking blocks as recently as the immediate previous block? + +* This should only be used when necessary (ie, the deeper block is not sufficient), and when the wallet can actively issue updates should the blockchain reorganise. +* While this allows intentionally creating a transaction which may be invalid in a reorganization, the same can already be accomplished by creating double spends. ==Backwards Compatibility== -- cgit v1.2.3