mirrors/bitcoin-bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-01-18 21:35:13 +01:00
Code Issues Projects Releases Wiki Activity

BIP65 assigned for CHECKLOCKTIMEVERIFY

Browse Source
This commit is contained in:
Peter Todd 2014-11-10 04:43:09 -05:00
parent 5f6cb04d9c
commit b05bc1ef53
No known key found for this signature in database
GPG Key ID: 2481403DA5F091FB
2 changed files with 23 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
README.mediawiki
View File

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

34
bip-checklocktimeverify.mediawiki → bip-0065.mediawiki
View File

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