summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorLuke Dashjr <luke-jr+git@utopios.org>2017-05-11 21:57:35 +0000
committerLuke Dashjr <luke-jr+git@utopios.org>2017-05-11 22:05:00 +0000
commitd7abc41bb62e4d43f16f6e89704cb90d77cc26b4 (patch)
tree677df9cb839f32a3d74d31d2950ffa9bee53e6c4
parentc624f9bfa57de55759a23621ff1e088164b1e07c (diff)
downloadbips-d7abc41bb62e4d43f16f6e89704cb90d77cc26b4.tar.xz
bip-noreplay: Remove relative height and redo depth limit
-rw-r--r--bip-noreplay.mediawiki22
1 files changed, 13 insertions, 9 deletions
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==