bitcoin/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-05-12 12:03:29 +00:00
Code Issues Releases Wiki Activity

Add more more example usecases and expand on summary

Browse Source
This commit is contained in:
BtcDrak 2015-10-03 23:14:20 +01:00
parent b962c479b3
commit 5273cdc3b9
1 changed files with 40 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

55
bip-0112.mediawiki
View File

@ -20,7 +20,11 @@ being spent.
CHECKSEQUENCEVERIFY redefines the existing NOP3 opcode. When executed it CHECKSEQUENCEVERIFY redefines the existing NOP3 opcode. When executed it
compares the top item on the stack to the nSequence field of the transaction compares the top item on the stack to the nSequence field of the transaction
input containing the scriptSig. ** input containing the scriptSig. If it is greater than or equal to (1 << 31),
or if the transaction version is greater than or equal to 2, the transaction
sequence is less than or equal to (1 << 31) and the top stack item is less than
the transaction sequence, script exection continues as if a NOP was executed,
otherwise the script fails.
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
@ -131,14 +135,14 @@ semantics and detailed rationale for those semantics.
// There are two kinds of nSequence: lock-by-blockheight // There are two kinds of nSequence: lock-by-blockheight
// and lock-by-blocktime, distinguished by whether // and lock-by-blocktime, distinguished by whether
// nSequence < nThreshold (SEQUENCE_UNITS_THRESHOLD). // nSequence < SEQUENCE_UNITS_THRESHOLD.
// //
// We want to compare apples to apples, so fail the script // We want to compare apples to apples, so fail the script
// unless the type of nSequence being tested is the same as // unless the type of nSequence being tested is the same as
// the nSequence in the transaction. // the nSequence in the transaction.
if (!( if (!(
(txToSequence < nThreshold && nSequence < nThreshold) || (txToSequence < SEQUENCE_UNITS_THRESHOLD && nSequence < SEQUENCE_UNITS_THRESHOLD) ||
(txToSequence >= nThreshold && nSequence >= nThreshold) (txToSequence >= SEQUENCE_UNITS_THRESHOLD && nSequence >= SEQUENCE_UNITS_THRESHOLD)
)) ))
return false; return false;
@ -151,7 +155,9 @@ semantics and detailed rationale for those semantics.
} }
==Example: Escrow with Timeout== ==Examples==
===Escrow with Timeout===
An escrow that times out automatically 30 days after being funded can be An escrow that times out automatically 30 days after being funded can be
established in the following way. Alice, Bob and Escrow create a 2-of-3 established in the following way. Alice, Bob and Escrow create a 2-of-3
@ -173,6 +179,25 @@ The clock does not start ticking until the payment to the escrow address
confirms. confirms.
===Payment Channel Revokation===
Scriptable relative locktime provides a predictable amount of time to respond in
the event a counterparty broadcasts a revoked transaction: Absolute locktime
necessitates closing the channel and reopen it when getting close to the timeout,
whereas with relative locktime, the clock starts ticking the moment the
transactions confirms in a block. It also provides a means to know exactly how
long to wait (in number of blocks) before funds can be pulled out of the channel
in the event of a noncooperative counterparty.
===Hash Time-Locked Contracts===
Hashed Timelock Contracts (HTLCs) can be used to create chains of payments which
is required for lightning network payment channels. The scheme requires both
CHECKSEQUENCEVERIFY and CHECKLOCKTIMEVERIFY to enforce HTLC timeouts and
revokation.
==Reference Implementation== ==Reference Implementation==
A reference implementation is provided in the following git repository: A reference implementation is provided in the following git repository:
@ -224,24 +249,24 @@ BtcDrak authored this BIP document.
==References== ==References==
BIP 68: Consensus-enforced transaction replacement signalled via [https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP 68] Consensus-enforced transaction replacement signalled via sequence numbers
sequence numbers
https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki
BIP 65: OP_CHECKLOCKTIMEVERIFY [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP 65] OP_CHECKLOCKTIMEVERIFY
https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki
BIP 113: Median past block time for time-lock constraints [https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki BIP 113] Median past block time for time-lock constraints
https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki
HTLCs using OP_CHECKSEQUENCEVERIFY/OP_LOCKTIMEVERIFY and [http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-July/000021.html HTLCs using OP_CHECKSEQUENCEVERIFY/OP_LOCKTIMEVERIFY and revocation hashes]
revocation hashes
http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-July/000021.html [http://lightning.network/lightning-network-paper.pdf Lightning Network]
[http://diyhpl.us/diyhpluswiki/transcripts/sf-bitcoin-meetup/2015-02-23-scaling-bitcoin-to-billions-of-transactions-per-day/ Scaling Bitcoin to Billions of Transactions Per Day]
[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010396.html Softfork deployment considerations] [http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010396.html Softfork deployment considerations]
[https://gist.github.com/sipa/bf69659f43e763540550 Version bits] [https://gist.github.com/sipa/bf69659f43e763540550 Version bits]
[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-April/002433.html Jeremy Spilman Micropayment Channels]
==Copyright== ==Copyright==