bip-noreplay: Merge in older no-cbah proposal which covers the same opcode

1 files changed, 38 insertions, 12 deletions

diff --git a/bip-noreplay.mediawiki b/bip-noreplay.mediawiki
index efd1a2c..127d7c8 100644
--- a/bip-noreplay.mediawiki
+++ b/bip-noreplay.mediawiki
@@ -7,13 +7,13 @@
   Comments-URI: FIXME
   Status: Draft
   Type: Standards Track
-  Created: 2017-01-26
+  Created: 2016-09-23
   License: BSD-2-Clause
 </pre>
 
 ==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.
+This BIP describes a new opcode (<code>OP_CHECKBLOCKATHEIGHT</code>) for the Bitcoin scripting system that allows construction of transactions which are valid only on specific blockchains.
 
 ==Copyright==
 
@@ -21,15 +21,18 @@ This BIP is licensed under the BSD 2-clause license.
 
 ==Specification==
 
-OP_CHECKBLOCKATHEIGHT redefines the existing NOP5 opcode.
+<code>OP_CHECKBLOCKATHEIGHT</code> redefines the existing <code>OP_NOP5</code> opcode.
 
-When executed, if any of the following conditions are true, the script interpreter will terminate with an error:
+When this opcode is executed:
 
-* the stack has fewer than 2 elements; or
-* the top item on the stack is not interpretable as a minimal-length CScriptNum; or
-* the top item on the stack, when interpreted as a block height (see below) is not within the range of allowed blocks; or
-* the second-to-top item on the stack, when interpreted as a block hash, has leading zeros; or
-* the second-to-top item on the stack does not match the block hash of the block specified by the top item on the stack interpreted as a height.
+* 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.
 
@@ -44,7 +47,7 @@ The specified height must not be more recent than the previous 100 blocks (that
 
 ===Deployment===
 
-This BIP will be deployed by "version bits" BIP9 with the '''name''' TBD and using '''bit''' TBD.
+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).
 
@@ -52,9 +55,32 @@ For Bitcoin '''mainnet''', the BIP9 '''starttime''' will be TBD (Epoch timestamp
 
 ==Motivation==
 
-In the event of a permanent 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.
+===Securely recovering from double spends===
 
-Additionally, there are some cases in normal Bitcoin operation wherein a wallet may need to respend a payment, but must guarantee its respend cannot be mined in the same block as a previous payment which has been recently conflicted by a double-spend.
+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 <code>OP_CHECKBLOCKATHEIGHT</code>, 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 <code>OP_CHECKBLOCKATHEIGHT</code>) common UTXOs to be spent only on chains based on that block.
+
+==Rationale==
+
+TODO
+
+==Backwards Compatibility==
+
+<code>OP_NOP5</code> 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==