summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorLuke Dashjr <luke-jr+git@utopios.org>2017-05-12 04:08:40 +0000
committerLuke Dashjr <luke-jr+git@utopios.org>2017-05-12 04:08:40 +0000
commit28621f70b53597ac7eab3e1f4a032a73019a6847 (patch)
treed37200137021767175c942862833e7c15ad99837
parent27b1d4944f5c4487f7567b45c0beb310fec8cbcc (diff)
downloadbips-28621f70b53597ac7eab3e1f4a032a73019a6847.tar.xz
bip-noreplay: Explain same-block and recent-block cases
-rw-r--r--bip-noreplay.mediawiki7
1 files changed, 5 insertions, 2 deletions
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==