From d7abc41bb62e4d43f16f6e89704cb90d77cc26b4 Mon Sep 17 00:00:00 2001 From: Luke Dashjr Date: Thu, 11 May 2017 21:57:35 +0000 Subject: bip-noreplay: Remove relative height and redo depth limit --- bip-noreplay.mediawiki | 22 +++++++++++++--------- 1 file changed, 13 insertions(+), 9 deletions(-) (limited to 'bip-noreplay.mediawiki') diff --git a/bip-noreplay.mediawiki b/bip-noreplay.mediawiki index 127d7c8..5fac80c 100644 --- a/bip-noreplay.mediawiki +++ b/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== -- cgit v1.2.3