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

Clarify some sections of text based on feedback, and convert to consistent styling for script examples.

Browse source
This commit is contained in:
Mark Friedenbach 2015-10-05 16:37:54 -07:00
parent cee01af153
commit 88507b49da
1 changed files with 63 additions and 64 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

127
bip-0112.mediawiki
View file

@ -19,13 +19,15 @@ being spent.
==Summary== ==Summary==
CHECKSEQUENCEVERIFY redefines the existing NOP3 opcode. When executed it CHECKSEQUENCEVERIFY redefines the existing NOP3 opcode.
compares the top item on the stack to the nSequence field of the transaction When executed, the script interpreter continues as if a NOP was executed
input containing the scriptSig. If it is greater than or equal to (1 << 31), so long as one of the following conditions is met:
or if the transaction version is greater than or equal to 2, the transaction input
sequence is less than or equal to (1 << 31) and the top stack item is less than * the transaction's nVersion field is 0 or 1;
the transaction input sequence, script exection continues as if a NOP was executed, * the top item on the stack is a value greater than or equal to (1 << 31); or
otherwise the script fails. * the top item on the stack and the transaction input's sequence number are both relative lock-times of the same units, and the relative lock-time represented by the sequence number is greater than or equal to the relative lock-time represented by the top item on the stack.
Otherwise, script execution terminates with an error.
BIP 68's redefinition of nSequence prevents a non-final transaction BIP 68's redefinition of nSequence prevents a non-final transaction
from being selected for inclusion in a block until the corresponding from being selected for inclusion in a block until the corresponding
@ -63,7 +65,7 @@ address with the following redeemscript.
IF IF
2 <Alice's pubkey> <Bob's pubkey> <Escrow's pubkey> 3 CHECKMULTISIGVERIFY 2 <Alice's pubkey> <Bob's pubkey> <Escrow's pubkey> 3 CHECKMULTISIGVERIFY
ELSE ELSE
<LOCKTIME_THRESHOLD + 30*24*60*60> CHECKSEQUENCEVERIFY DROP "30d" CHECKSEQUENCEVERIFY DROP
<Alice's pubkey> CHECKSIGVERIFY <Alice's pubkey> CHECKSIGVERIFY
ENDIF ENDIF
@ -98,7 +100,7 @@ Some more specific applications of this idea:
====Hash Time-Locked Contracts==== ====Hash Time-Locked Contracts====
Hash Time-Locked Contracts (HTLCs) provide a general mechanism for offchain contract negotiation. An execution pathway can be made to require knowledge of a secret (a hash preimage) that can be presented within an invalidation time window. By sharing the secret it is possible to guarantee to the counterparty that the transaction will never be broadcast since this would allow the counterparty to claim the output immediately while one would have to wait for the time window to pass. If the secret has not been shared, the counterparty will be unable to use the instant pathway and the delayed pathway will be used instead. Hash Time-Locked Contracts (HTLCs) provide a general mechanism for offchain contract negotiation. An execution pathway can be made to require knowledge of a secret (a hash preimage) that can be presented within an invalidation time window. By sharing the secret it is possible to guarantee to the counterparty that the transaction will never be broadcast since this would allow the counterparty to claim the output immediately while one would have to wait for the time window to pass. If the secret has not been shared, the counterparty will be unable to use the instant pathway and the delayed pathway must be used instead.
====Bidirectional Payment Channels==== ====Bidirectional Payment Channels====
@ -138,13 +140,13 @@ thus committing to not relaying the old transaction.
A simple output, paying to Alice might then look like: A simple output, paying to Alice might then look like:
OP_HASH160 <revokehash> OP_EQUAL HASH160 <revokehash> EQUAL
OP_IF IF
OP_DUP OP_HASH160 <Bob key hash> OP_CHECKSIGVERIFY DUP HASH160 <Bob key hash> CHECKSIGVERIFY
OP_ELSE ELSE
24h OP_CHECKSEQUENCEVERIFY "24h" CHECKSEQUENCEVERIFY
OP_DUP OP_HASH160 <Alice key hash> OP_CHECKSIGVERIFY DUP HASH160 <Alice key hash> CHECKSIGVERIFY
OP_ENDIF ENDIF
This allows Alice to publish the latest commitment transaction at any This allows Alice to publish the latest commitment transaction at any
time and spend the funds after 24 hours, but also ensures that if Alice time and spend the funds after 24 hours, but also ensures that if Alice
@ -152,13 +154,13 @@ relays a revoked transaction, that Bob has 24 hours to claim the funds.
With CHECKLOCKTIMEVERIFY, this would look like: With CHECKLOCKTIMEVERIFY, this would look like:
OP_HASH160 <revokehash> OP_EQUAL HASH160 <revokehash> EQUAL
OP_IF IF
OP_DUP OP_HASH160 <Bob key hash> OP_CHECKSIGVERIFY DUP HASH160 <Bob key hash> CHECKSIGVERIFY
OP_ELSE ELSE
2015/12/15 OP_CHECKLOCKTIMEVERIFY "2015/12/15" CHECKLOCKTIMEVERIFY
OP_DUP OP_HASH160 <Alice key hash> OP_CHECKSIGVERIFY DUP HASH160 <Alice key hash> CHECKSIGVERIFY
OP_ENDIF ENDIF
This form of transaction would mean that if the anchor is unspent on This form of transaction would mean that if the anchor is unspent on
2015/12/16, Alice can use this commitment even if it has been revoked, 2015/12/16, Alice can use this commitment even if it has been revoked,
@ -167,7 +169,7 @@ simply by spending it immediately, giving no time for Bob to claim it.
Ths means that the channel has a deadline that cannot be pushed Ths means that the channel has a deadline that cannot be pushed
back without hitting the blockchain; and also that funds may not be back without hitting the blockchain; and also that funds may not be
available until the deadline is hit. CHECKSEQUENCEVERIFY allows you available until the deadline is hit. CHECKSEQUENCEVERIFY allows you
to avoid making that tradeoff. to avoid making such a tradeoff.
Hashed Time-Lock Contracts (HTLCs) make this slightly more complicated, Hashed Time-Lock Contracts (HTLCs) make this slightly more complicated,
since in principle they may pay either Alice or Bob, depending on whether since in principle they may pay either Alice or Bob, depending on whether
@ -177,35 +179,35 @@ delay, and the entire output can be claimed by the other party if the
revocation secret is known. With CHECKSEQUENCEVERIFY, a HTLC payable to revocation secret is known. With CHECKSEQUENCEVERIFY, a HTLC payable to
Alice might look like the following in Alice's commitment transaction: Alice might look like the following in Alice's commitment transaction:
OP_HASH160 OP_DUP <revokehash> OP_EQUAL HASH160 DUP <revokehash> EQUAL
OP_IF IF
OP_DROP OP_DUP OP_HASH160 <Bob key hash> OP_CHECKSIGVERIFY DROP DUP HASH160 <Bob key hash> CHECKSIGVERIFY
OP_ELSE ELSE
<R hash> OP_EQUAL <R hash> EQUAL
OP_IF IF
"24h" OP_CHECKSEQUENCEVERIFY OP_DROP "24h" CHECKSEQUENCEVERIFY DROP
OP_DUP OP_HASH160 <Alice key hash> OP_CHECKSIGVERIFY DUP HASH160 <Alice key hash> CHECKSIGVERIFY
OP_ELSE ELSE
"2015/10/20 10:33" OP_CHECKLOCKTIMEVERIFY OP_DROP "2015/10/20 10:33" CHECKLOCKTIMEVERIFY DROP
OP_DUP OP_HASH160 <Bob key hash> OP_CHECKSIGVERIFY DUP HASH160 <Bob key hash> CHECKSIGVERIFY
OP_ENDIF ENDIF
OP_ENDIF ENDIF
and correspondingly in Bob's commitment transaction: and correspondingly in Bob's commitment transaction:
OP_HASH160 OP_DUP <revokehash> OP_EQUAL HASH160 DUP <revokehash> EQUAL
OP_IF IF
OP_DROP OP_DUP OP_HASH160 <Alice key hash> OP_CHECKSIGVERIFY DROP DUP HASH160 <Alice key hash> CHECKSIGVERIFY
OP_ELSE ELSE
<R hash> OP_EQUAL <R hash> EQUAL
OP_IF IF
OP_DUP OP_HASH160 <Alice key hash> OP_CHECKSIGVERIFY DUP HASH160 <Alice key hash> CHECKSIGVERIFY
OP_ELSE ELSE
"24h" OP_CHECKSEQUENCEVERIFY OP_DROP "24h" CHECKSEQUENCEVERIFY DROP
"2015/10/20 10:33" OP_CHECKLOCKTIMEVERIFY OP_DROP "2015/10/20 10:33" CHECKLOCKTIMEVERIFY DROP
OP_DUP OP_HASH160 <Bob key hash> OP_CHECKSIGVERIFY DUP HASH160 <Bob key hash> CHECKSIGVERIFY
OP_ENDIF ENDIF
OP_ENDIF ENDIF
Note that both CHECKSEQUENCEVERIFY and CHECKLOCKTIMEVERIFY are used in the Note that both CHECKSEQUENCEVERIFY and CHECKLOCKTIMEVERIFY are used in the
final branch of above to ensure Bob cannot spend the output until after both final branch of above to ensure Bob cannot spend the output until after both
@ -217,11 +219,13 @@ See the [https://github.com/ElementsProject/lightning/blob/master/doc/deployable
====2-Way Pegged Sidechains==== ====2-Way Pegged Sidechains====
OP_IF The 2-way pegged sidechain requires a new REORGPROOFVERIFY opcode, the semantics of which are outside the scope of this BIP. CHECKSEQUENCEVERIFY is used to make sure that sufficient time has passed since the return peg was posted to publish a reorg proof:
lockTxHeight <lockTxHash> nlocktxOut [<workAmount>] reorgBounty Hash160(<...>) <genesisHash> OP_REORGPROOFVERIFY
OP_ELSE IF
withdrawLockTime OP_CHECKSEQUENCEVERIFY OP_DROP OP_HASH160 p2shWithdrawDest OP_EQUAL lockTxHeight <lockTxHash> nlocktxOut [<workAmount>] reorgBounty Hash160(<...>) <genesisHash> REORGPROOFVERIFY
OP_ENDIF ELSE
withdrawLockTime CHECKSEQUENCEVERIFY DROP HASH160 p2shWithdrawDest EQUAL
ENDIF
==Specification== ==Specification==
@ -258,14 +262,9 @@ semantics and detailed rationale for those semantics.
// range. This limitation is implemented by CScriptNum's // range. This limitation is implemented by CScriptNum's
// default 4-byte limit. // default 4-byte limit.
// //
// If we kept to that limit we'd have a year 2038 problem,
// even though the nLockTime field in transactions
// themselves is uint32 which only becomes meaningless
// after the year 2106.
//
// Thus as a special case we tell CScriptNum to accept up // Thus as a special case we tell CScriptNum to accept up
// to 5-byte bignums, which are good until 2**39-1, well // to 5-byte bignums, which are good until 2**39-1, well
// beyond the 2**32-1 limit of the nLockTime field itself. // beyond the 2**32-1 limit of the nSequence field itself.
const CScriptNum nSequence(stacktop(-1), fRequireMinimal, 5); const CScriptNum nSequence(stacktop(-1), fRequireMinimal, 5);
// In the rare event that the argument may be < 0 due to // In the rare event that the argument may be < 0 due to
@ -281,13 +280,13 @@ semantics and detailed rationale for those semantics.
break; break;
// Actually compare the specified sequence number with the input. // Actually compare the specified sequence number with the input.
if (!CheckSequence(nSequence)) if (!checker.CheckSequence(nSequence))
return set_error(serror, SCRIPT_ERR_UNSATISFIED_LOCKTIME); return set_error(serror, SCRIPT_ERR_UNSATISFIED_LOCKTIME);
break; break;
} }
bool CheckSequence(const CScriptNum& nSequence) const bool TransactionSignatureChecker::CheckSequence(const CScriptNum& nSequence) const
{ {
// Relative lock times are supported by comparing the passed // Relative lock times are supported by comparing the passed
// in operand to the sequence number of the input. // in operand to the sequence number of the input.
@ -321,7 +320,7 @@ semantics and detailed rationale for those semantics.
// Now that we know we're comparing apples-to-apples, the // Now that we know we're comparing apples-to-apples, the
// comparison is a simple numeric one. // comparison is a simple numeric one.
if (nSequence > txToSequence) if (txTo->vin[nIn].nSequence > txToSequence)
return false; return false;
return true; return true;