mirrors/bitcoin-bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-02-23 07:15:30 +01:00
Code Issues Projects Releases Wiki Activity

bip-noreplay: Remove relative height and redo depth limit

Browse source
This commit is contained in:
Luke Dashjr 2017-05-11 21:57:35 +00:00
parent c624f9bfa5
commit d7abc41bb6
1 changed files with 13 additions and 9 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

22
bip-noreplay.mediawiki
View file

@ -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==