BIP: ?
Layer: Consensus (soft fork)
Title: Generic anti-replay protection using Script
Author: Luke Dashjr
Comments-Summary: No comments yet.
Comments-URI: FIXME
Status: Draft
Type: Standards Track
Created: 2016-09-23
License: BSD-2-Clause
==Abstract==
This BIP describes a new opcode (OP_CHECKBLOCKATHEIGHT
) for the Bitcoin scripting system that allows construction of transactions which are valid only on specific blockchains.
==Copyright==
This BIP is licensed under the BSD 2-clause license.
==Specification==
OP_CHECKBLOCKATHEIGHT
redefines the existing OP_NOP5
opcode.
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).
* 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.
* 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.
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.
For Bitcoin '''mainnet''', the BIP9 '''starttime''' will be TBD (Epoch timestamp TBD) and BIP9 '''timeout''' will be TBD (Epoch timestamp TBD).
For Bitcoin '''mainnet''', the BIP9 '''starttime''' will be TBD (Epoch timestamp TBD) and BIP9 '''timeout''' will be TBD (Epoch timestamp TBD).
==Motivation==
===Securely recovering from double spends===
In some circumstances, users may wish to spend received bitcoins before they have confirmed on the blockchain (Tx B1).
However, if the transaction sending them those bitcoins (Tx A1) is double-spent, the wallet must re-issue their own transaction spending them (Tx B2).
So long as the double-spend of the incoming transaction (Tx A2) also pays the wallet, this can be managed by simply updating the outgoing transaction with the new outpoint and resigning.
However, if the double-spend does not pay the wallet, the situation is presently irrecoverable:
it must spend different, non-conflicting TXOs in Tx B2, which allows an attacker to then reorganise the chain (reversing the incoming transaction's double-spend) and confirm both of his transactions Tx B1 and Tx B2.
By adding OP_CHECKBLOCKATHEIGHT
, the wallet can issue Tx B2 with a condition that the block confirming Tx A2 is in the history, thus eliminating this risk.
===Replay protection in the event of a persistent blockchain split===
In the event of a persistent blockchain split, some mechanism is desired by which the UTXOs valid in either chain may be spent without the transaction being validly replayable on the other chain.
This can be guaranteed by choosing a block which exists only on either side of the split, and pinning (using OP_CHECKBLOCKATHEIGHT
) common UTXOs to be spent only on chains based on that block.
==Rationale==
TODO
==Backwards Compatibility==
OP_NOP5
ought to be forbidden by policy by all miners for future extensions such as this, so old miners will under no circumstances produce blocks which would now be considered invalid under the new rules.
However, miners must still upgrade to avoid accepting and building on top of such a possible invalid block as part of an attack.
Old nodes will likely also not relay transactions using this opcode for the same extensibility reasons, but this is not important since the rule cannot be verified deterministically outside the context of a block.
==Reference Implementation==
TODO