ZIP: 68 +Title: Relative lock-time using consensus-enforced sequence numbers +Credits: Mark Friedenbach <mark@friedenbach.org> + BtcDrak <btcdrak@gmail.com> + Nicolas Dorier <nicolas.dorier@gmail.com> + kinoshitajona <kinoshitajona@gmail.com> +Category: Consensus +Status: Draft +Created: 2016-06-06+
Terminology 
+ The key words "MUST" and "MAY" in this document are to be interpreted as described in RFC 2119. 1
+The "Median Time Past" of a block in this document is to be interpreted as described in 4.
+Abstract
+ This ZIP introduces relative lock-time (RLT) consensus-enforced semantics of the sequence number field, to enable a signed transaction input to remain invalid for a defined period of time after confirmation of its corresponding outpoint.
+Motivation
+ Zcash transactions have a sequence number field for each input, inherited from Bitcoin. The original idea in Bitcoin appears to have been that a transaction in the mempool would be replaced by using the same input with a higher sequence value. Although this was not properly implemented, it assumes miners would prefer higher sequence numbers even if the lower ones were more profitable to mine. However, a miner acting on profit motives alone would break that assumption completely. The change described by this ZIP repurposes the sequence number for new use cases without breaking existing functionality. It also leaves room for future expansion and other use cases.
+The transaction nLockTime is used to prevent the mining of a transaction until a certain date. nSequence will be repurposed to prevent mining of a transaction until a certain age of the spent output in blocks or timespan. This, among other uses, allows bi-directional payment channels as used in 5 and 3.
Specification
+ This specification defines the meaning of sequence numbers for transactions in blocks after this proposal has activated.
+If bit (1 << 31) of the sequence number is set, then no consensus meaning is applied to the sequence number and can be included in any block under all currently possible circumstances.
+If bit (1 << 31) of the sequence number is not set, then the sequence number is interpreted as an encoded relative lock-time.
+The sequence number encoding MUST be interpreted as follows:
+Bit (1 << 22) determines if the relative lock-time is time-based or block based: If the bit is set, the relative lock-time specifies a timespan in units of 32 seconds granularity. The timespan starts from the Median Time Past of the output’s previous block, and ends at the Median Time Past of the previous block. If the bit is not set, the relative lock-time specifies a number of blocks.
+Note: the 64-second time unit differs from Bitcoin's BIP 68, which uses a 512-second time unit.
+The flag (1 << 22) is the highest order bit in a 3-byte signed integer for use in Zcash scripts as a 3-byte PUSHDATA with OP_CHECKSEQUENCEVERIFY 3.
This specification only interprets 22 bits of the sequence number as relative lock-time, so a mask of 0x003FFFFF MUST be applied to the sequence field to extract the relative lock-time. The 22-bit specification allows for over 8.5 years of relative lock-time.
+ For time-based relative lock-time, 64-second granularity was chosen because the block target spacing for Zcash, after activation of the Blossom network upgrade, is 75 seconds. So when using block-based or time-based, roughly the same amount of time can be encoded with the available number of bits. Converting from a sequence number to seconds is performed by multiplying by 64.
+When the relative lock-time is time-based, it is interpreted as a minimum block-time constraint over the input's age. A relative time-based lock-time of zero indicates an input which can be included in any block. More generally, a relative time-based lock-time n can be included into any block produced 64 * n seconds after the mining date of the output it is spending, or any block thereafter. The mining date of the output is equal to the Median Time Past of the previous block that mined it.
+The block produced time is equal to the Median Time Past of its previous block.
+When the relative lock-time is block-based, it is interpreted as a minimum block-height constraint over the input's age. A relative block-based lock-time of zero indicates an input that can be included in any block. More generally, a relative block lock-time n MAY be included n blocks after the mining date of the output it is spending, or any block thereafter.
+The new rules are not applied to the nSequence field of the input of the coinbase transaction.
Reference Implementation
+
+ Acknowledgments
+ This ZIP is based on BIP 68, authored by Mark Friedenbach, BtcDrak, Nicolas Dorier, and kinoshitajona.
+Credit goes to Gregory Maxwell for providing a succinct and clear description of the behavior of this change, which became the basis of the BIP text.
+Deployment
+ At the time of writing it has not been decided which network upgrade (if any) will implement this proposal.
+This ZIP is designed to be deployed simultaneously with 3 and 4.
+Compatibility
+ The only use of sequence numbers by the zcashd reference client software is to disable checking the nLockTime constraints in a transaction. The semantics of that application are preserved by this ZIP.
As can be seen from the specification section, a number of bits are undefined by this ZIP to allow for other use cases by setting bit (1 << 31) as the remaining 31 bits have no meaning under this ZIP. Additionally, bits (1 << 23) through (1 << 30) inclusive have no meaning at all when bit (1 << 31) is unset.
+Unlike BIP 68 in Bitcoin, all of the low 22 bits are used for the value. This reflects the fact that blocks are more frequent (75 seconds instead of 600 seconds), and so more bits are needed to obtain approximately the same range of time.
+The most efficient way to calculate sequence number from relative lock-time is with bit masks and shifts:
+ +References
+ | 1 | +Key words for use in RFCs to Indicate Requirement Levels | +
|---|
| 2 | +Bitcoin mailing list discussion | +
|---|
| 3 | +ZIP 112: CHECKSEQUENCEVERIFY | +
|---|
| 4 | +ZIP 113: Median Time Past as endpoint for lock-time calculations | +
|---|
| 5 | +Reaching The Ground With Lightning (draft 0.2) | +
|---|
ZIP: 112 +Title: CHECKSEQUENCEVERIFY +Author: Daira Hopwood <daira@electriccoin.co> +Credits: BtcDrak <btcdrak@gmail.com> + Mark Friedenbach <mark@friedenbach.org> + Eric Lombrozo <elombrozo@gmail.com> +Category: Consensus +Status: Draft +Created: 2019-06-06 +License: MIT+
Terminology
+ The key word "MUST" in this document is to be interpreted as described in RFC 2119. 1
+Abstract
+ This ZIP describes a new opcode (CHECKSEQUENCEVERIFY) for the Zcash scripting system, that in combination with ZIP 68 allows execution pathways of a script to be restricted based on the age of the output being spent.
Motivation
+ ZIP 68 repurposes the transaction nSequence field meaning by giving sequence numbers new consensus-enforced semantics as a relative lock-time. However, there is no way to build Zcash scripts to make decisions based on this field.
By making the nSequence field accessible to script, it becomes possible to construct code pathways that only become accessible some minimum time after proof-of-publication. This enables a wide variety of applications in phased protocols such as escrow, payment channels, or bidirectional pegs.
Specification
+ CHECKSEQUENCEVERIFY redefines the existing NOP3 opcode. When executed, if any of the following conditions are true, the script interpreter MUST terminate with an error:
-
+
- the stack is empty; or +
- the top item on the stack is less than 0; or +
- the top item on the stack has the disable flag (1 << 31) unset; and any of the following hold:
+
-
+
- the transaction version is less than 2; or +
- the transaction input sequence number disable flag (1 << 31) is set; or +
- the relative lock-time type is not the same; or +
- the top stack item is greater than the transaction input sequence (when masked according to 4; +
+
Otherwise, script execution MUST continue as if a NOP had been executed.
ZIP 68 prevents a non-final transaction from being selected for inclusion in a block until the corresponding input has reached the specified age, as measured in block-height or block-time. By comparing the argument to CHECKSEQUENCEVERIFY against the nSequence field, we indirectly verify a desired minimum age of the the output being spent; until that relative age has been reached any script execution pathway including the CHECKSEQUENCEVERIFY will fail to validate, causing the transaction not to be selected for inclusion in a block.
Use cases
+ Contracts With Expiration Deadlines
+ Escrow with Timeout
+ 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 address with the following redeem script:
+IF + 2 <Alice's pubkey> <Bob's pubkey> <Escrow's pubkey> 3 CHECKMULTISIG +ELSE + "30d" CHECKSEQUENCEVERIFY DROP + <Alice's pubkey> CHECKSIG +ENDIF+
At any time funds can be spent using signatures from any two of Alice, Bob or the Escrow.
+After 30 days Alice can sign alone.
+The clock does not start ticking until the payment to the escrow address confirms.
+Retroactive Invalidation
+ In many instances, we would like to create contracts that can be revoked in case of some future event. However, given the immutable nature of the block chain, it is practically impossible to retroactively invalidate a previous commitment that has already confirmed. The only mechanism we really have for retroactive invalidation is block chain reorganization which, for fundamental security reasons, is designed to be very hard and very expensive to do.
+Despite this limitation, we do have a way to provide something functionally similar to retroactive invalidation while preserving irreversibility of past commitments using CHECKSEQUENCEVERIFY. By constructing scripts with multiple branches of execution where one or more of the branches are delayed we provide a time window in which someone can supply an invalidation condition that allows the output to be spent, effectively invalidating the would-be delayed branch and potentially discouraging another party from broadcasting the transaction in the first place. If the invalidation condition does not occur before the timeout, the delayed branch becomes spendable, honoring the original contract.
Some more specific applications of this idea:
+Hash Time-Locked Contracts
+ Hash Time-Locked Contracts (HTLCs) provide a general mechanism for off-chain 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
+ 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 reopening it when getting close to the timeout, whereas with relative locktime, the clock starts ticking the moment the transaction 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.
+Lightning Network
+ The lightning network protocol 6 extends the bidirectional payment channel idea to allow for payments to be routed over multiple bidirectional payment channel hops.
+These channels are based on an anchor transaction that requires a 2-of-2 multisig from Alice and Bob, and a series of revocable commitment transactions that spend the anchor transaction. The commitment transaction splits the funds from the anchor between Alice and Bob and the latest commitment transaction may be published by either party at any time, finalising the channel.
+Ideally then, a revoked commitment transaction would never be able to be successfully spent; and the latest commitment transaction would be able to be spent very quickly.
+To allow a commitment transaction to be effectively revoked, Alice and Bob have slightly different versions of the latest commitment transaction. In Alice's version, any outputs in the commitment transaction that pay Alice also include a forced delay, and an alternative branch that allows Bob to spend the output if he knows that transaction's revocation code. In Bob's version, payments to Bob are similarly encumbered. When Alice and Bob negotiate new balances and new commitment transactions, they also reveal the old revocation code, thus committing to not relaying the old transaction.
+A simple output, paying to Alice might then look like:
+HASH160 <revokehash> EQUAL +IF + <Bob's pubkey> +ELSE + "24h" CHECKSEQUENCEVERIFY DROP + <Alice's pubkey> +ENDIF +CHECKSIG+
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 relays a revoked transaction, that Bob has 24 hours to claim the funds.
+With CHECKLOCKTIMEVERIFY, this would look like:
HASH160 <revokehash> EQUAL +IF + <Bob's pubkey> +ELSE + "2015/12/15" CHECKLOCKTIMEVERIFY DROP + <Alice's pubkey> +ENDIF +CHECKSIG+
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, simply by spending it immediately, giving no time for Bob to claim it.
+This means that the channel has a deadline that cannot be pushed back without hitting the blockchain; and also that funds may not be available until the deadline is hit. CHECKSEQUENCEVERIFY allows you to avoid making such a tradeoff.
Hashed Time-Lock Contracts (HTLCs) make this slightly more complicated, since in principle they may pay either Alice or Bob, depending on whether Alice discovers a secret R, or a timeout is reached, but the same principle applies -- the branch paying Alice in Alice's commitment transaction gets a delay, and the entire output can be claimed by the other party if the revocation secret is known. With CHECKSEQUENCEVERIFY, a HTLC payable to Alice might look like the following in Alice's commitment transaction:
HASH160 DUP <R-HASH> EQUAL +IF + "24h" CHECKSEQUENCEVERIFY + 2DROP + <Alice's pubkey> +ELSE + <Commit-Revocation-Hash> EQUAL + NOTIF + "2015/10/20 10:33" CHECKLOCKTIMEVERIFY DROP + ENDIF + <Bob's pubkey> +ENDIF +CHECKSIG+
and correspondingly in Bob's commitment transaction:
+HASH160 DUP <R-HASH> EQUAL +SWAP <Commit-Revocation-Hash> EQUAL ADD +IF + <Alice's pubkey> +ELSE + "2015/10/20 10:33" CHECKLOCKTIMEVERIFY + "24h" CHECKSEQUENCEVERIFY + 2DROP + <Bob's pubkey> +ENDIF +CHECKSIG+
Note that both CHECKSEQUENCEVERIFY and CHECKLOCKTIMEVERIFY are used in the final branch above to ensure Bob cannot spend the output until after both the timeout is complete and Alice has had time to reveal the revocation secret.
See also the 'Deployable Lightning' paper 5.
+2-Way Pegged Sidechains
+ The 2-way pegged sidechain requires a new REORGPROOFVERIFY opcode, the semantics of which are outside the scope of this ZIP. CHECKSEQUENCEVERIFY is used to make sure that sufficient time has passed since the return peg was posted to publish a reorg proof:
IF + lockTxHeight <lockTxHash> nlocktxOut [<workAmount>] reorgBounty Hash160(<...>) <genesisHash> REORGPROOFVERIFY +ELSE + withdrawLockTime CHECKSEQUENCEVERIFY DROP HASH160 p2shWithdrawDest EQUAL +ENDIF+
Reference Implementation
+
+ Deployment
+ At the time of writing it has not been decided which network upgrade (if any) will implement this proposal.
+This ZIP must be deployed simultaneously with ZIP 68 4.
+Acknowledgements
+ This ZIP is closely based on BIP 112, authored by BtcDrak.
+Mark Friedenbach invented the application of sequence numbers to achieve relative lock-time, and wrote the reference implementation of CHECKSEQUENCEVERIFY for Bitcoin.
The Bitcoin reference implementation and BIP 112 was based heavily on work done by Peter Todd for the closely related BIP 65. Eric Lombrozo and Anthony Towns contributed example use cases.
+References
+ | 1 | +Key words for use in RFCs to Indicate Requirement Levels | +
|---|
| 2 | +Zcash Protocol Specification, Version 2019.0.1 or later [Overwinter+Sapling] | +
|---|
| 3 | +BIP 65: OP_CHECKLOCKTIMEVERIFY | +
|---|
| 4 | +ZIP 68: Relative lock-time through consensus-enforced sequence numbers | +
|---|
| 5 | +Deployable Lightning | +
|---|
| 6 | +Lightning Network paper | +
|---|
| 7 | +HTLCs using OP_CHECKSEQUENCEVERIFY/OP_LOCKTIMEVERIFY and revocation hashes | +
|---|
| 8 | +Scaling Bitcoin to Billions of Transactions Per Day | +
|---|
| 9 | +Jeremy Spilman, Micropayment Channels | +
|---|
ZIP: 113 +Title: Median Time Past as endpoint for lock-time calculations +Author: Daira Hopwood <daira@electriccoin.co> +Credits: Thomas Kerin <me@thomaskerin.io> + Mark Friedenbach <mark@friedenbach.org> + Gregory Maxwell +Category: Consensus +Status: Draft +Created: 2019-06-07 +License: MIT+
Terminology
+ The key words "MUST" and "MAY" in this document are to be interpreted as described in RFC 2119. 1
+Abstract
+ This ZIP is a proposal to redefine the semantics used in determining a time-locked transaction's eligibility for inclusion in a block. The median of the last PoWMedianBlockSpan (11) blocks is used instead of the block's timestamp, ensuring that it increases monotonically with each block.
+Motivation
+ At present, transactions are excluded from inclusion in a block if the present time or block height is less than or equal to that specified in the locktime. Since the consensus rules do not mandate strict ordering of block timestamps, this has the unfortunate outcome of creating a perverse incentive for miners to lie about the time of their blocks in order to collect more fees by including transactions that by wall clock determination have not yet matured.
+This ZIP proposes comparing the locktime against the median of the past PoWMedianBlockSpan blocks' timestamps, rather than the timestamp of the block including the transaction. Existing consensus rules guarantee this value to monotonically advance, thereby removing the capability for miners to claim more transaction fees by lying about the timestamps of their block.
+This proposal seeks to ensure reliable behaviour in locktime calculations as required by 3 (CHECKLOCKTIMEVERIFY) and matching the behavior of 5 (CHECKSEQUENCEVERIFY). This also matches the use of Median Time Past in difficulty adjustment as specified in section 7.6.3 of 2.
+Specification
+ Let PoWMedianBlockSpan be as defined in 2 section 5.3, and let the median function be as defined in 2 section 7.6.3.
+The Median Time Past of a block is specified as the median of the timestamps of the prior PoWMedianBlockSpan blocks, as calculated by MedianTime(height) in 2 section 7.6.3.
+The values for transaction locktime remain unchanged. The difference is only in the calculation determining whether a transaction can be included. After activation of this ZIP, lock-time constraints of a transaction MUST be checked according to the Median Time Past of the transaction's block.
+[FIXME make this a proper specification, independent of the zcashd implementation.]
+Lock-time constraints are checked by the consensus method IsFinalTx(). This method takes the block time as one parameter. This ZIP proposes that after activation calls to IsFinalTx() within consensus code use the return value of GetMedianTimePast(pindexPrev) instead.
The new rule applies to all transactions, including the coinbase transaction.
+Reference Implementation
+ This will be based on Bitcoin PR 6566.
+Acknowledgements
+ This ZIP is based on BIP 113, authored by Thomas Kerin and Mark Friedenbach.
+Mark Friedenbach designed and authored the reference implementation for Bitcoin.
+Gregory Maxwell came up with the original idea, in #bitcoin-wizards on 2013-07-16 and 2013-07-17.
+Deployment
+ At the time of writing it has not been decided which network upgrade (if any) will implement this proposal.
+This ZIP is designed to be deployed simultaneously with 4 and 5.
+Compatibility
+ At the post-Blossom block target spacing of 75 seconds, transactions generated using time-based lock-time will take approximately 7.5 minutes longer to confirm than would be expected under the old rules. This is not known to introduce any compatibility concerns with existing protocols. This delay is less than in Bitcoin due to the faster block target spacing in Zcash.
+References
+ | 1 | +Key words for use in RFCs to Indicate Requirement Levels | +
|---|
| 2 | +Zcash Protocol Specification, Version 2019.0.1 or later [Overwinter+Sapling+Blossom] | +
|---|
| 3 | +BIP 65: OP_CHECKLOCKTIMEVERIFY | +
|---|
| 4 | +ZIP 68: Consensus-enforced transaction replacement signaled via sequence numbers | +
|---|
| 5 | +ZIP 112: CHECKSEQUENCEVERIFY | +
|---|
This ZIP refines the specification of the third case.
The following specification constrains a party, called the "reader", that interprets the contents of a memo. It does not define consensus requirements.
-
-
- If the first byte (byte 0) has a value of 0xF4 or smaller, then the reader MUST: +
- If the first byte (byte 0) has a value of
0xF4or smaller, then the reader MUST:- strip any trailing zero bytes
- decode it as a UTF-8 string (if decoding fails then report an error).
- - If the first byte has a value of 0xF6, and the remaining 511 bytes are 0x00, then the user supplied no memo, and the encrypted memo field is to be treated as empty. +
- If the first byte has a value of
0xF6, and the remaining 511 bytes are0x00, then the user supplied no memo, and the encrypted memo field is to be treated as empty. - If the memo matches any of these patterns, then this memo is from the future, because these ranges are reserved for future updates to this specification:
-
-
- The first byte has a value of 0xF5. -
- The first byte has a value of 0xF6, and the remaining 511 bytes are not all 0x00. -
- The first byte has a value between 0xF7 and 0xFE inclusive. +
- The first byte has a value of
0xF6, and the remaining 511 bytes are not all0x00.
+ - The first byte has a value between
0xF7and0xFEinclusive.
- - If the first byte has a value of 0xFF then the reader should not make any other assumption about the memo. In order to put arbitrary data into a memo field (that might have some private non-standard structure), the value of the first byte SHOULD be set to 0xFF; the remaining 511 bytes are then unconstrained. +
- If the first byte has a value of
0xFFthen the reader should not make any other assumption about the memo. In order to put arbitrary data into a memo field (that might have some private non-standard structure), the value of the first byte SHOULD be set to 0xFF; the remaining 511 bytes are then unconstrained.
+ - If the first byte has a value of
0xF5, then the reader should not make any other assumption about the memo. This value was used ambiguously in the past by private agreement; applications SHOULD prefer0xFFwhich is unambiguously for this purpose.
Rationale
@@ -54,10 +54,10 @@
The usage of the memo field is by agreement between the sender and recipient of the note. The memo field SHOULD be encoded either as:
- a UTF-8 human-readable string [Unicode], padded by appending zero bytes; or -
- an arbitrary sequence of 512 bytes starting with a byte value of 0xF5 or greater, which is therefore not a valid UTF-8 string. +
- an arbitrary sequence of 512 bytes starting with a byte value of
0xF5or greater, which is therefore not a valid UTF-8 string.
In the former case, wallet software is expected to strip any trailing zero bytes and then display the resulting UTF-8 string to the recipient user, where applicable. Incorrect UTF-8-encoded byte sequences should be displayed as replacement characters (U+FFFD).
-In the latter case, the contents of the memo field SHOULD NOT be displayed. A start byte of 0xF5 is reserved for use by automated software by private agreement. A start byte of 0xF6 or greater is reserved for use in future Zcash protocol extensions.
+In the former case, wallet software is expected to strip any trailing zero bytes and then display the resulting UTF-8 string to the recipient user, where applicable. Incorrect UTF-8-encoded byte sequences should be displayed as replacement characters (U+FFFD).
In the latter case, the contents of the memo field SHOULD NOT be displayed. A start byte of 0xF5 is reserved for use by automated software by private agreement. A start byte of 0xF6 or greater is reserved for use in future Zcash protocol extensions.
See issue #1849 for further discussion.