summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--README.mediawiki6
-rw-r--r--bip-0065.mediawiki (renamed from bip-checklocktimeverify.mediawiki)34
2 files changed, 23 insertions, 17 deletions
diff --git a/README.mediawiki b/README.mediawiki
index ea9783a..8ad9e17 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -236,6 +236,12 @@ Those proposing changes should consider that ultimately consent may rest with th
| Standard
| Draft
|-
+| [[bip-0065.mediawiki|65]]
+| OP_CHECKLOCKTIMEVERIFY
+| Peter Todd
+| Standard
+| Draft
+|-
| [[bip-0070.mediawiki|70]]
| Payment protocol
| Gavin Andresen
diff --git a/bip-checklocktimeverify.mediawiki b/bip-0065.mediawiki
index ee88c51..9574374 100644
--- a/bip-checklocktimeverify.mediawiki
+++ b/bip-0065.mediawiki
@@ -1,5 +1,5 @@
<pre>
- BIP:
+ BIP: 65
Title: OP_CHECKLOCKTIMEVERIFY
Author: Peter Todd <pete@petertodd.org>
Status: Draft
@@ -85,13 +85,13 @@ funds with the following scriptSig:
===Non-interactive time-locked refunds===
There exist a number of protocols where a transaction output is created that
-the co-operation of both parties to spend the output. To ensure the failure of
-one party does not result in the funds becoming lost refund transactions are
-setup in advance using nLockTime. These refund transactions need to be created
-interactively, and additionaly, are currently vulnerable to transaction
-mutability. CHECKLOCKTIMEVERIFY can be used in these protocols, replacing the
-interactive setup with a non-interactive setup, and additionally, making
-transaction mutability a non-issue.
+requires the co-operation of both parties to spend the output. To ensure the
+failure of one party does not result in the funds becoming lost refund
+transactions are setup in advance using nLockTime. These refund transactions
+need to be created interactively, and additionaly, are currently vulnerable to
+transaction mutability. CHECKLOCKTIMEVERIFY can be used in these protocols,
+replacing the interactive setup with a non-interactive setup, and additionally,
+making transaction mutability a non-issue.
====Two-factor wallets====
@@ -193,13 +193,13 @@ semantics and detailed rationale for those semantics.
// CHECKLOCKTIMEVERIFY
//
// (nLockTime -- nLockTime )
-
+
if (!(flags & SCRIPT_VERIFY_CHECKLOCKTIMEVERIFY))
break; // not enabled; treat as a NOP
-
+
if (stack.size() < 1)
return false;
-
+
// Note that elsewhere numeric opcodes are limited to
// operands in the range -2**31+1 to 2**31-1, however it is
// legal for opcodes to produce results exceeding that
@@ -215,13 +215,13 @@ semantics and detailed rationale for those semantics.
// to 5-byte bignums, which are good until 2**32-1, the
// same limit as the nLockTime field itself.
const CScriptNum nLockTime(stacktop(-1), 5);
-
+
// In the rare event that the argument may be < 0 due to
// some arithmetic being done first, you can always use
// 0 MAX CHECKLOCKTIMEVERIFY.
if (nLockTime < 0)
return false;
-
+
// There are two times of nLockTime: lock-by-blockheight
// and lock-by-blocktime, distinguished by whether
// nLockTime < LOCKTIME_THRESHOLD.
@@ -234,12 +234,12 @@ semantics and detailed rationale for those semantics.
(txTo.nLockTime >= LOCKTIME_THRESHOLD && nLockTime >= LOCKTIME_THRESHOLD)
))
return false;
-
+
// Now that we know we're comparing apples-to-apples, the
// comparison is a simple numeric one.
if (nLockTime > (int64_t)txTo.nLockTime)
return false;
-
+
// Finally the nLockTime feature can be disabled and thus
// CHECKLOCKTIMEVERIFY bypassed if every txin has been
// finalized by setting nSequence to maxint. The
@@ -252,9 +252,9 @@ semantics and detailed rationale for those semantics.
// required to prove correct CHECKLOCKTIMEVERIFY execution.
if (txTo.vin[nIn].IsFinal())
return false;
-
+
break;
-
+
}
https://github.com/petertodd/bitcoin/commit/ab0f54f38e08ee1e50ff72f801680ee84d0f1bf4