<p>This is a Standards ZIP describing a new consensus rule to set an expiration time after which a transaction cannot be mined. If it is not mined within that time, the transaction will be removed from nodes' mempools.</p>
<p>Transactions that have insufficient fees are often not mined. This indeterminism is a source of confusion for users and wallets. Allowing a transaction to set a block height after which it cannot be mined would provide certainty around how long a transaction has to confirm before it is rejected by the network and must be re-sent.</p>
<p>Advantages include optimizing mempool performance by removing transactions that will not be mined, and potentially simplifying bidirectional payment channels by reducing the need to store and compress revocations for past states, since transactions not committed to the chain could expire and become invalid after a period of time.</p>
<p>Transactions will have a new field, <code>nExpiryHeight</code>, which will set the block height after which transactions will be removed from the mempool if they have not been mined.</p>
<p>The data type for <code>nExpiryHeight</code> will be <code>uint32_t</code>. If used in combination with <code>nLockTime</code>, both <code>nLockTime</code> and <code>nExpiryHeight</code> must be block heights. <code>nExpiryHeight</code> will never be a UNIX timestamp, unlike <code>nLockTime</code> values, and thus the maximum expiry height will be 499999999 (but see the exception for coinbase transactions described in <ahref="#changes-for-nu5">Changes for NU5</a>).</p>
<p>For the example below, the last block that the transaction below could possibly be included in is 3539. After that, it will be removed from the mempool.</p>
<p>Default: 20 blocks from the current height, or about 50 minutes at 2.5-minute target block spacing. A configuration option can be used to set the user's default.</p>
<p>Minimum: No minimum</p>
<p>Maximum: 499999999, which is about 1185 years from now at 75 seconds/block.</p>
<p>No limit: To set no limit on transactions (so that they do not expire), <code>nExpiryHeight</code> should be set to 0.</p>
<p>Coinbase: <code>nExpiryHeight</code> on coinbase transactions is ignored, and is set to 0 by convention.</p>
<sectionid="changes-for-blossom"><h3><spanclass="section-heading">Changes for Blossom</span><spanclass="section-anchor"><arel="bookmark"href="#changes-for-blossom"><imgwidth="24"height="24"class="section-anchor"src="assets/images/section-anchor.png"alt=""></a></span></h3>
<p>On Blossom activation <aid="id1"class="footnote_reference"href="#zip-0206">2</a>, the default changes to 40 blocks from the current height, which still represents about 50 minutes at the revised 75-second target block spacing.</p>
<sectionid="changes-for-nu5"><h3><spanclass="section-heading">Changes for NU5</span><spanclass="section-anchor"><arel="bookmark"href="#changes-for-nu5"><imgwidth="24"height="24"class="section-anchor"src="assets/images/section-anchor.png"alt=""></a></span></h3>
<p>As mentioned above, <code>nExpiryHeight</code> is ignored for coinbase transactions. However, from NU5 activation <aid="id2"class="footnote_reference"href="#zip-0252">3</a>, the <code>nExpiryHeight</code> field of a coinbase transaction MUST be set equal to the block height. Also, for coinbase transactions only, the bound of 499999999 on <code>nExpiryHeight</code> is removed. The motivation is to ensure that transaction IDs remain unique, as explained in more detail in a note in Section 7.1 of the protocol specification <aid="id3"class="footnote_reference"href="#protocol-txnencoding">4</a>.</p>
<sectionid="wallet-behavior-and-ui"><h3><spanclass="section-heading">Wallet behavior and UI</span><spanclass="section-anchor"><arel="bookmark"href="#wallet-behavior-and-ui"><imgwidth="24"height="24"class="section-anchor"src="assets/images/section-anchor.png"alt=""></a></span></h3>
<p>With the addition of this feature, zero-confirmation transactions with an expiration block height set will have even less guarantee of inclusion. This means that UIs and services must never rely on zero-confirmation transactions in Zcash.</p>
<p>Wallet should notify the user of expired transactions that must be re-sent.</p>
<p>This feature will be deployed with Overwinter. The activation blockheight proposal is in <aid="id4"class="footnote_reference"href="#zip-0201">1</a>.</p>