bip-noreplay: Remove relative height and redo depth limit

Author: luke-jr

bip-noreplay.mediawiki

@@ -27,9 +27,9 @@ 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, see below).
+* 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 ParamHeight is not within the range of allowed blocks, the script fails.
+* 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 or has leading zeros, the script fails.
 * If ParamBlockHash does not match the block hash of the block specified by ParamHeight, the script fails.
@@ -38,13 +38,6 @@ Otherwise, script execution will continue as if a NOP had been executed.
 
 FIXME: some way to mask out parts of the block hash for gambling/deterministic-random applications?
 
-===Block height interpretation and limits===
-
-The specified block height may be either a negative number to specify a relative height, or a positive number for an absolute height.
-A value of -1 refers to the block immediately preceding the block the transaction is mined it (but this is not a valid value, note).
-
-The specified height must not be more recent than the previous 100 blocks (that is, the largest negative value allowed is -101), nor older than 262144 blocks prior (ie, the smallest negative value is -262144).
-
 ===Deployment===
 
 This BIP will be deployed by "version bits" [[bip-0009.mediawiki|BIP9]] with the '''name''' "cbah" and using '''bit''' TBD.
@@ -73,6 +66,17 @@ This can be guaranteed by choosing a block which exists only on either side of t
 
 ==Rationale==
 
+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.
+
+Why are blocks older than 52596 deep in the chain not verified?
+
+* This is to avoid creating an infinite storage requirement from all full nodes which would be necessary to maintain all the block headers indefinitely. 52596 block headers requires a fixed size of approximately 4 MB.
+* In any case where you might want to specify a deeper block, you can also just as well specify a more recent one that decends from it.
+* It is assumed that 1 year is sufficient time to double-spend any common UTXOs on all blockchains of interest.
+* If a deeper check is needed, it can be softforked in. Making the check more shallow, on the other hand, is a hardfork.
+
 TODO
 
 ==Backwards Compatibility==