From c762384bd610351d70fba351f80c10d1bc9950e7 Mon Sep 17 00:00:00 2001 From: Jay Graber Date: Mon, 8 Jan 2018 19:37:22 -0800 Subject: [PATCH 01/15] Add draft --- drafts/arcalinea-tx-expiry/draft.rst | 0 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 drafts/arcalinea-tx-expiry/draft.rst diff --git a/drafts/arcalinea-tx-expiry/draft.rst b/drafts/arcalinea-tx-expiry/draft.rst new file mode 100644 index 00000000..e69de29b From ca9c36fed5667a0de45fefc69bdcba49a5c34421 Mon Sep 17 00:00:00 2001 From: Jay Graber Date: Tue, 9 Jan 2018 16:43:07 -0800 Subject: [PATCH 02/15] Add to tx expiry draft --- drafts/arcalinea-tx-expiry/draft.rst | 54 ++++++++++++++++++++++++++++ 1 file changed, 54 insertions(+) diff --git a/drafts/arcalinea-tx-expiry/draft.rst b/drafts/arcalinea-tx-expiry/draft.rst index e69de29b..2e1114ee 100644 --- a/drafts/arcalinea-tx-expiry/draft.rst +++ b/drafts/arcalinea-tx-expiry/draft.rst @@ -0,0 +1,54 @@ +**Title:** Transaction Expiry + +**Author:** Jay Graber + +**Status:** Active + +**Category:** Standards + +**Created:** 2018-01-09 + +Abstract +=========== + +This is an Standards ZIP describing a new consensus rule to expire transactions that are not mined from the mempool. + +Motivation +=========== + +Transactions that are too large or have insufficient fees are often not mined. This indeterminism is a source of confusion for users and wallets. Giving users the ability to specify the number of blocks a transaction should sit in the mempool before it expires, and otherwise setting a default, would provide certainty around how long a transaction has to confirm. + +Advantages include improving performance by removing transactions unlikely to be mined, and simplifying bidirectional payment channels by reducing the need to store and compress revocations for past states since transactions are allowed to expire. + +Specification +=============== + +Transactions will have a new field, nBlockExpiry, which will set the blockheight after which transactions will be removed from the mempool if they have not been mined. The last block that the transaction below could possibly be included in is 3539. After that, it will be removed from the mempool. + +```` +"txid": "17561b98cc77cd5a984bb959203e073b5f33cf14cbce90eb32b95ae2c796723f", +"version": 3, +"locktime": 2089, +"blockexpiry": 3539, +``` + +With the addition of this feature, zero-confirmation transactions with an expiration blockheight set will have even less guarantee of inclusion. This means that UIs and services must never rely on zero-confirmation transactions in Zcash. + +Default behavior +----------------- + +Default behavior does not change -- transactions do not expire. (Alternative proposal is to set a default expiry period of 2 days, ~1440 blocks.) + +If used in combination with nLockTime, nLockTime must be a blockheight, and nBlockExpiry must be higher. To simplify this feature, we could disallow its use in conjunction with nLockTime. + +Upon block reorg +----------------- + +Transactions that are confirmed close to the end of their expiry period may be dropped from the mempool upon a block reorg, which could leave dependent transactions stranded in the mempool. Therefore, each time an expired transaction is removed from the mempool, a check must be added to remove its dependent transactions as well. + +Wallet behavior and UI +----------------------- + +Wallet should notify user of expired transactions that must be re-sent. + +Wallet should notify user and reject the creation of a transaction that builds on a transaction with zero confirmations and an expiry blockheight set. From 202058fa7620f50834e74751dcec8266247a570c Mon Sep 17 00:00:00 2001 From: Jay Graber Date: Wed, 10 Jan 2018 11:59:04 -0800 Subject: [PATCH 03/15] Add wallet behavior --- drafts/arcalinea-tx-expiry/draft.rst | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drafts/arcalinea-tx-expiry/draft.rst b/drafts/arcalinea-tx-expiry/draft.rst index 2e1114ee..f07ae872 100644 --- a/drafts/arcalinea-tx-expiry/draft.rst +++ b/drafts/arcalinea-tx-expiry/draft.rst @@ -37,7 +37,7 @@ With the addition of this feature, zero-confirmation transactions with an expira Default behavior ----------------- -Default behavior does not change -- transactions do not expire. (Alternative proposal is to set a default expiry period of 2 days, ~1440 blocks.) +Default behavior does not change -- transactions do not expire. (Alternative proposal is to set a default expiry period of 2 days, ~1440 blocks.) When nBlockExpiry is set to 0, the transaction will not expire from the mempool. If used in combination with nLockTime, nLockTime must be a blockheight, and nBlockExpiry must be higher. To simplify this feature, we could disallow its use in conjunction with nLockTime. @@ -52,3 +52,10 @@ Wallet behavior and UI Wallet should notify user of expired transactions that must be re-sent. Wallet should notify user and reject the creation of a transaction that builds on a transaction with zero confirmations and an expiry blockheight set. + +RPC interface +-------------- + +sendtoaddress will allow the user to easily set a blockheight for the transaction to expire. + +sendtoaddress "zcashaddress" amount ( blockexpiry "comment" "comment-to" subtractfeefromamount ) From 6111c1e6399e48b92a46f8d12418f5013cb5aab8 Mon Sep 17 00:00:00 2001 From: Jay Graber Date: Thu, 11 Jan 2018 14:37:52 -0800 Subject: [PATCH 04/15] Draft 2 for nExpiryTime --- drafts/arcalinea-tx-expiry/draft.rst | 45 ++++++++++++++++++---------- 1 file changed, 30 insertions(+), 15 deletions(-) diff --git a/drafts/arcalinea-tx-expiry/draft.rst b/drafts/arcalinea-tx-expiry/draft.rst index f07ae872..d87b81f6 100644 --- a/drafts/arcalinea-tx-expiry/draft.rst +++ b/drafts/arcalinea-tx-expiry/draft.rst @@ -11,19 +11,23 @@ Abstract =========== -This is an Standards ZIP describing a new consensus rule to expire transactions that are not mined from the mempool. +This is an Standards ZIP describing a new consensus rule to set an expiration time for transactions that are not mined to be removed from the mempool. Motivation =========== -Transactions that are too large or have insufficient fees are often not mined. This indeterminism is a source of confusion for users and wallets. Giving users the ability to specify the number of blocks a transaction should sit in the mempool before it expires, and otherwise setting a default, would provide certainty around how long a transaction has to confirm. +Transactions that are too large or have insufficient fees are often not mined. This indeterminism is a source of confusion for users and wallets. Allowing transactions to set a block height or timestamp after which it expires from the mempool would provide certainty around how long a transaction has to confirm before it is rejected by the network and must be re-sent. -Advantages include improving performance by removing transactions unlikely to be mined, and simplifying bidirectional payment channels by reducing the need to store and compress revocations for past states since transactions are allowed to expire. +Advantages include improving performance by removing transactions unlikely to 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. Specification =============== -Transactions will have a new field, nBlockExpiry, which will set the blockheight after which transactions will be removed from the mempool if they have not been mined. The last block that the transaction below could possibly be included in is 3539. After that, it will be removed from the mempool. +Transactions will have a new field, nExpiryTime, which will set the block height or UNIX timestamp after which transactions will be removed from the mempool if they have not been mined. + +The data type for nExpiryTime will be uint32_t, conforming to the structure of nLockTime. If used in combination with nLockTime, both nLockTime and nExpiryTime must be the same unit (either block height or timestamp). + +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. ```` "txid": "17561b98cc77cd5a984bb959203e073b5f33cf14cbce90eb32b95ae2c796723f", @@ -32,30 +36,41 @@ Transactions will have a new field, nBlockExpiry, which will set the blockheight "blockexpiry": 3539, ``` -With the addition of this feature, zero-confirmation transactions with an expiration blockheight set will have even less guarantee of inclusion. This means that UIs and services must never rely on zero-confirmation transactions in Zcash. +Default: nExpiryTime defaults to 0, which means transaction does not expire, preserving current behavior. +Minimum: When nExpiryTime is set, it must be at least 60 blocks greater than the current blockheight, or 2 hrs greater than LOCKTIME_MEDIAN_TIME_PAST. This is because of the safety thresholds specified below. +Maximum: No maximum specified, although based on the highest timestamp available for uint32 numbers, nExpiryTime becomes meaningless after the year 2106. -Default behavior ------------------ +Timeline of expiration safety thresholds +----------------------------------------- -Default behavior does not change -- transactions do not expire. (Alternative proposal is to set a default expiry period of 2 days, ~1440 blocks.) When nBlockExpiry is set to 0, the transaction will not expire from the mempool. +2 hours before a transaction is set to expire, other nodes stop relaying it. +1 hour before expiring, CreateNewBlock does not include the tx anymore. This is in case mining software changes the timestamp afterwards, resulting in the mining of an invalid block that contains expired transactions. +1 hour after expiring, wallet marks the transaction as expired and frees the coins. -If used in combination with nLockTime, nLockTime must be a blockheight, and nBlockExpiry must be higher. To simplify this feature, we could disallow its use in conjunction with nLockTime. +Another reason to set a minimum expiration period is to mitigate the use of this feature as a spam mechanism. -Upon block reorg ------------------ +Upon block reorganization +-------------------------- Transactions that are confirmed close to the end of their expiry period may be dropped from the mempool upon a block reorg, which could leave dependent transactions stranded in the mempool. Therefore, each time an expired transaction is removed from the mempool, a check must be added to remove its dependent transactions as well. Wallet behavior and UI ----------------------- +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. + Wallet should notify user of expired transactions that must be re-sent. Wallet should notify user and reject the creation of a transaction that builds on a transaction with zero confirmations and an expiry blockheight set. -RPC interface --------------- +RPC +----- +listtransactions has a new filter attribute, showing expired transactions only: + listtransactions "*" 10 0 "expired" -sendtoaddress will allow the user to easily set a blockheight for the transaction to expire. +WalletTxToJSON shows a boolean expired true/false -sendtoaddress "zcashaddress" amount ( blockexpiry "comment" "comment-to" subtractfeefromamount ) +Notify +-------- + +-expirenotify= can notify an external script when a wallet transaction expires From 0b0ce007b3d6e4fc8472ac237362011848b75344 Mon Sep 17 00:00:00 2001 From: Jay Graber Date: Thu, 11 Jan 2018 16:45:25 -0800 Subject: [PATCH 05/15] Changes after overwinter meeting --- drafts/arcalinea-tx-expiry/draft.rst | 31 ++++++++++++++-------------- 1 file changed, 15 insertions(+), 16 deletions(-) diff --git a/drafts/arcalinea-tx-expiry/draft.rst b/drafts/arcalinea-tx-expiry/draft.rst index d87b81f6..22d718e4 100644 --- a/drafts/arcalinea-tx-expiry/draft.rst +++ b/drafts/arcalinea-tx-expiry/draft.rst @@ -16,16 +16,16 @@ This is an Standards ZIP describing a new consensus rule to set an expiration ti Motivation =========== -Transactions that are too large or have insufficient fees are often not mined. This indeterminism is a source of confusion for users and wallets. Allowing transactions to set a block height or timestamp after which it expires from the mempool would provide certainty around how long a transaction has to confirm before it is rejected by the network and must be re-sent. +Transactions that are too large or have insufficient fees are often not mined. This indeterminism is a source of confusion for users and wallets. Allowing transactions to set a block height after which it expires from the mempool would provide certainty around how long a transaction has to confirm before it is rejected by the network and must be re-sent. Advantages include improving performance by removing transactions unlikely to 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. Specification =============== -Transactions will have a new field, nExpiryTime, which will set the block height or UNIX timestamp after which transactions will be removed from the mempool if they have not been mined. +Transactions will have a new field, nBlockExpiry, which will set the block height after which transactions will be removed from the mempool if they have not been mined. -The data type for nExpiryTime will be uint32_t, conforming to the structure of nLockTime. If used in combination with nLockTime, both nLockTime and nExpiryTime must be the same unit (either block height or timestamp). +The data type for nBlockExpiry will be uint32_t, conforming to the structure of nLockTime. If used in combination with nLockTime, both nLockTime and nBlockExpiry must be block heights. 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. @@ -36,18 +36,11 @@ For the example below, the last block that the transaction below could possibly "blockexpiry": 3539, ``` -Default: nExpiryTime defaults to 0, which means transaction does not expire, preserving current behavior. -Minimum: When nExpiryTime is set, it must be at least 60 blocks greater than the current blockheight, or 2 hrs greater than LOCKTIME_MEDIAN_TIME_PAST. This is because of the safety thresholds specified below. -Maximum: No maximum specified, although based on the highest timestamp available for uint32 numbers, nExpiryTime becomes meaningless after the year 2106. +Default: TBD. One suggestion is 576 blocks, or about 1 day assuming 2.5 minute block times. Can add a config option to set user's default. +Minimum: No minimum +Maximum: 500000000, about 380 years +No limit: To set no limit on transactions (so that they do not expire), nBlockExpiry should be set to UINT_MAX. -Timeline of expiration safety thresholds ------------------------------------------ - -2 hours before a transaction is set to expire, other nodes stop relaying it. -1 hour before expiring, CreateNewBlock does not include the tx anymore. This is in case mining software changes the timestamp afterwards, resulting in the mining of an invalid block that contains expired transactions. -1 hour after expiring, wallet marks the transaction as expired and frees the coins. - -Another reason to set a minimum expiration period is to mitigate the use of this feature as a spam mechanism. Upon block reorganization -------------------------- @@ -59,18 +52,24 @@ Wallet behavior and UI 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. -Wallet should notify user of expired transactions that must be re-sent. +Wallet should notify user of expired transactions that must be re-sent. See "Notify" section below. Wallet should notify user and reject the creation of a transaction that builds on a transaction with zero confirmations and an expiry blockheight set. RPC ----- +To use: +To make changes to the sendtoaddress and z_sendmany commands backwards compatible for future changes, keyword arguments should be accepted by the RPC interface. Since this is not consensus critical behavior, it can be added in a future release. For Overwinter, tx expiry will be set to a default that can be overridden by a flag `txexpirydefault` set in the config file. + +-txexpirydefault= set default for tx expiry + +To view: listtransactions has a new filter attribute, showing expired transactions only: listtransactions "*" 10 0 "expired" WalletTxToJSON shows a boolean expired true/false Notify --------- +------- -expirenotify= can notify an external script when a wallet transaction expires From 1ad89c9a475b3c81c7908042520da853fc098df0 Mon Sep 17 00:00:00 2001 From: Jay Graber Date: Mon, 29 Jan 2018 12:46:13 -0800 Subject: [PATCH 06/15] Incorporate feedback --- drafts/arcalinea-tx-expiry/draft.rst | 23 +++++++---------------- 1 file changed, 7 insertions(+), 16 deletions(-) diff --git a/drafts/arcalinea-tx-expiry/draft.rst b/drafts/arcalinea-tx-expiry/draft.rst index 22d718e4..7cee759c 100644 --- a/drafts/arcalinea-tx-expiry/draft.rst +++ b/drafts/arcalinea-tx-expiry/draft.rst @@ -16,16 +16,16 @@ This is an Standards ZIP describing a new consensus rule to set an expiration ti Motivation =========== -Transactions that are too large or have insufficient fees are often not mined. This indeterminism is a source of confusion for users and wallets. Allowing transactions to set a block height after which it expires from the mempool would provide certainty around how long a transaction has to confirm before it is rejected by the network and must be re-sent. +Transactions that have insufficient fees are often not mined. This indeterminism is a source of confusion for users and wallets. Allowing transactions to set a block height after which it expires from the mempool would provide certainty around how long a transaction has to confirm before it is rejected by the network and must be re-sent. If the expiry is block height N, it means the transaction must have either: 1. have been included in N-1, or 2. be included in block N. N+1 will be too late, and the transaction will be removed from the mempool. -Advantages include improving performance by removing transactions unlikely to 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. +Advantages include optimizing mempool performance by removing transactions unlikely to 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. Specification =============== Transactions will have a new field, nBlockExpiry, which will set the block height after which transactions will be removed from the mempool if they have not been mined. -The data type for nBlockExpiry will be uint32_t, conforming to the structure of nLockTime. If used in combination with nLockTime, both nLockTime and nBlockExpiry must be block heights. +The data type for nBlockExpiry will be uint32_t. If used in combination with nLockTime, both nLockTime and nBlockExpiry must be block heights. nBlockExpiry will never be a UNIX timestamp, unlike nLockTime values. 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. @@ -36,16 +36,12 @@ For the example below, the last block that the transaction below could possibly "blockexpiry": 3539, ``` -Default: TBD. One suggestion is 576 blocks, or about 1 day assuming 2.5 minute block times. Can add a config option to set user's default. +Default: TBD. Current proposal is 24 blocks, or about 1 hour assuming 2.5 minute block times. Can add a config option to set user's default. Minimum: No minimum Maximum: 500000000, about 380 years -No limit: To set no limit on transactions (so that they do not expire), nBlockExpiry should be set to UINT_MAX. +No limit: To set no limit on transactions (so that they do not expire), nBlockExpiry should be set to UINT_MAX. - -Upon block reorganization --------------------------- - -Transactions that are confirmed close to the end of their expiry period may be dropped from the mempool upon a block reorg, which could leave dependent transactions stranded in the mempool. Therefore, each time an expired transaction is removed from the mempool, a check must be added to remove its dependent transactions as well. +Every time a transaction expires and should be removed from the mempool, so should all its dependent transactions. Wallet behavior and UI ----------------------- @@ -54,7 +50,7 @@ With the addition of this feature, zero-confirmation transactions with an expira Wallet should notify user of expired transactions that must be re-sent. See "Notify" section below. -Wallet should notify user and reject the creation of a transaction that builds on a transaction with zero confirmations and an expiry blockheight set. +Wallet should notify user when building on a transaction with zero confirmations and an expiry blockheight set. Message TBD. RPC ----- @@ -68,8 +64,3 @@ listtransactions has a new filter attribute, showing expired transactions only: listtransactions "*" 10 0 "expired" WalletTxToJSON shows a boolean expired true/false - -Notify -------- - --expirenotify= can notify an external script when a wallet transaction expires From 94ae904055da2c773d3d3cebf0504aa2ef22a509 Mon Sep 17 00:00:00 2001 From: Jay Graber Date: Fri, 2 Feb 2018 23:07:04 -0800 Subject: [PATCH 07/15] Add user configurable --- drafts/arcalinea-tx-expiry/draft.rst | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drafts/arcalinea-tx-expiry/draft.rst b/drafts/arcalinea-tx-expiry/draft.rst index 7cee759c..7d9b0704 100644 --- a/drafts/arcalinea-tx-expiry/draft.rst +++ b/drafts/arcalinea-tx-expiry/draft.rst @@ -64,3 +64,10 @@ listtransactions has a new filter attribute, showing expired transactions only: listtransactions "*" 10 0 "expired" WalletTxToJSON shows a boolean expired true/false + +Config +------- + +Default will be user configurable with flag `txblockexpirydelta` + +`--txblockexpirydelta=100` From 8df1c1f3309feaa1a9a79e39793b7b9b3717f91f Mon Sep 17 00:00:00 2001 From: Jay Graber Date: Mon, 12 Feb 2018 12:33:44 -0800 Subject: [PATCH 08/15] s/nBlockExpiry/nExpiryHeight --- drafts/arcalinea-tx-expiry/draft.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drafts/arcalinea-tx-expiry/draft.rst b/drafts/arcalinea-tx-expiry/draft.rst index 7d9b0704..ea1674d0 100644 --- a/drafts/arcalinea-tx-expiry/draft.rst +++ b/drafts/arcalinea-tx-expiry/draft.rst @@ -23,9 +23,9 @@ Advantages include optimizing mempool performance by removing transactions unlik Specification =============== -Transactions will have a new field, nBlockExpiry, which will set the block height after which transactions will be removed from the mempool if they have not been mined. +Transactions will have a new field, nExpiryHeight, which will set the block height after which transactions will be removed from the mempool if they have not been mined. -The data type for nBlockExpiry will be uint32_t. If used in combination with nLockTime, both nLockTime and nBlockExpiry must be block heights. nBlockExpiry will never be a UNIX timestamp, unlike nLockTime values. +The data type for nExpiryHeight will be uint32_t. If used in combination with nLockTime, both nLockTime and nExpiryHeight must be block heights. nExpiryHeight will never be a UNIX timestamp, unlike nLockTime values. 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. @@ -39,7 +39,7 @@ For the example below, the last block that the transaction below could possibly Default: TBD. Current proposal is 24 blocks, or about 1 hour assuming 2.5 minute block times. Can add a config option to set user's default. Minimum: No minimum Maximum: 500000000, about 380 years -No limit: To set no limit on transactions (so that they do not expire), nBlockExpiry should be set to UINT_MAX. +No limit: To set no limit on transactions (so that they do not expire), nExpiryHeight should be set to UINT_MAX. Every time a transaction expires and should be removed from the mempool, so should all its dependent transactions. From 37321a546dbbc0d80be7709c53b48c6be6c72c98 Mon Sep 17 00:00:00 2001 From: Jay Graber Date: Mon, 12 Feb 2018 12:34:13 -0800 Subject: [PATCH 09/15] s/blockexpiry/expiryheight --- drafts/arcalinea-tx-expiry/draft.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drafts/arcalinea-tx-expiry/draft.rst b/drafts/arcalinea-tx-expiry/draft.rst index ea1674d0..864ae87b 100644 --- a/drafts/arcalinea-tx-expiry/draft.rst +++ b/drafts/arcalinea-tx-expiry/draft.rst @@ -33,7 +33,7 @@ For the example below, the last block that the transaction below could possibly "txid": "17561b98cc77cd5a984bb959203e073b5f33cf14cbce90eb32b95ae2c796723f", "version": 3, "locktime": 2089, -"blockexpiry": 3539, +"expiryheight": 3539, ``` Default: TBD. Current proposal is 24 blocks, or about 1 hour assuming 2.5 minute block times. Can add a config option to set user's default. From fcbe13b2bd93ba4897ca3778698a35103041266c Mon Sep 17 00:00:00 2001 From: Jay Graber Date: Mon, 12 Feb 2018 12:36:41 -0800 Subject: [PATCH 10/15] Set to 0 for no expiry --- drafts/arcalinea-tx-expiry/draft.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drafts/arcalinea-tx-expiry/draft.rst b/drafts/arcalinea-tx-expiry/draft.rst index 864ae87b..7e61a7b8 100644 --- a/drafts/arcalinea-tx-expiry/draft.rst +++ b/drafts/arcalinea-tx-expiry/draft.rst @@ -39,7 +39,7 @@ For the example below, the last block that the transaction below could possibly Default: TBD. Current proposal is 24 blocks, or about 1 hour assuming 2.5 minute block times. Can add a config option to set user's default. Minimum: No minimum Maximum: 500000000, about 380 years -No limit: To set no limit on transactions (so that they do not expire), nExpiryHeight should be set to UINT_MAX. +No limit: To set no limit on transactions (so that they do not expire), nExpiryHeight should be set to 0. Every time a transaction expires and should be removed from the mempool, so should all its dependent transactions. From e74cf69d4e34a5d620fa4536b25edc60df5d26b2 Mon Sep 17 00:00:00 2001 From: Jay Graber Date: Mon, 12 Feb 2018 12:38:52 -0800 Subject: [PATCH 11/15] Edits --- drafts/arcalinea-tx-expiry/draft.rst | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drafts/arcalinea-tx-expiry/draft.rst b/drafts/arcalinea-tx-expiry/draft.rst index 7e61a7b8..69827846 100644 --- a/drafts/arcalinea-tx-expiry/draft.rst +++ b/drafts/arcalinea-tx-expiry/draft.rst @@ -16,16 +16,18 @@ This is an Standards ZIP describing a new consensus rule to set an expiration ti Motivation =========== -Transactions that have insufficient fees are often not mined. This indeterminism is a source of confusion for users and wallets. Allowing transactions to set a block height after which it expires from the mempool would provide certainty around how long a transaction has to confirm before it is rejected by the network and must be re-sent. If the expiry is block height N, it means the transaction must have either: 1. have been included in N-1, or 2. be included in block N. N+1 will be too late, and the transaction will be removed from the mempool. +Transactions that have insufficient fees are often not mined. This indeterminism is a source of confusion for users and wallets. Allowing transactions to set a block height after which it expires from the mempool would provide certainty around how long a transaction has to confirm before it is rejected by the network and must be re-sent. Advantages include optimizing mempool performance by removing transactions unlikely to 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. +If the expiry is block height N, it means the transaction must have either: 1. have been included in N-1, or 2. be included in block N. N+1 will be too late, and the transaction will be removed from the mempool. + Specification =============== Transactions will have a new field, nExpiryHeight, which will set the block height after which transactions will be removed from the mempool if they have not been mined. -The data type for nExpiryHeight will be uint32_t. If used in combination with nLockTime, both nLockTime and nExpiryHeight must be block heights. nExpiryHeight will never be a UNIX timestamp, unlike nLockTime values. +The data type for nExpiryHeight will be uint32_t. If used in combination with nLockTime, both nLockTime and nExpiryHeight must be block heights. nExpiryHeight will never be a UNIX timestamp, unlike nLockTime values, and thus the maximum expiry height will be 500000000. 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. From 9b0453ed8e63d232cfb82688fb9f535123d0c450 Mon Sep 17 00:00:00 2001 From: Jay Graber Date: Fri, 23 Feb 2018 15:18:06 -0800 Subject: [PATCH 12/15] Add coinbase rule --- drafts/arcalinea-tx-expiry/draft.rst | 1 + 1 file changed, 1 insertion(+) diff --git a/drafts/arcalinea-tx-expiry/draft.rst b/drafts/arcalinea-tx-expiry/draft.rst index 69827846..ae2ad14a 100644 --- a/drafts/arcalinea-tx-expiry/draft.rst +++ b/drafts/arcalinea-tx-expiry/draft.rst @@ -42,6 +42,7 @@ Default: TBD. Current proposal is 24 blocks, or about 1 hour assuming 2.5 minute Minimum: No minimum Maximum: 500000000, about 380 years No limit: To set no limit on transactions (so that they do not expire), nExpiryHeight should be set to 0. +Coinbase: nExpiryHeight on coinbase transactions is ignored, and is set to 0 by convention. Every time a transaction expires and should be removed from the mempool, so should all its dependent transactions. From da67f85ba4f1d0f1f9a6abfd12938092a1d07a73 Mon Sep 17 00:00:00 2001 From: Jay Graber Date: Fri, 23 Feb 2018 16:02:53 -0800 Subject: [PATCH 13/15] Change maximum, state nExpiryHeight is 0 on coinbase by convention --- drafts/arcalinea-tx-expiry/draft.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drafts/arcalinea-tx-expiry/draft.rst b/drafts/arcalinea-tx-expiry/draft.rst index ae2ad14a..4bcd9af4 100644 --- a/drafts/arcalinea-tx-expiry/draft.rst +++ b/drafts/arcalinea-tx-expiry/draft.rst @@ -40,7 +40,7 @@ For the example below, the last block that the transaction below could possibly Default: TBD. Current proposal is 24 blocks, or about 1 hour assuming 2.5 minute block times. Can add a config option to set user's default. Minimum: No minimum -Maximum: 500000000, about 380 years +Maximum: 499999999, about 380 years No limit: To set no limit on transactions (so that they do not expire), nExpiryHeight should be set to 0. Coinbase: nExpiryHeight on coinbase transactions is ignored, and is set to 0 by convention. From af1932e303dbff01d0c1f614cedda77a7496c452 Mon Sep 17 00:00:00 2001 From: Jay Graber Date: Thu, 1 Mar 2018 11:50:34 -0800 Subject: [PATCH 14/15] Incorporate tromer, daira feedback --- drafts/arcalinea-tx-expiry/draft.rst | 37 +++++++++++++++++----------- 1 file changed, 22 insertions(+), 15 deletions(-) diff --git a/drafts/arcalinea-tx-expiry/draft.rst b/drafts/arcalinea-tx-expiry/draft.rst index 4bcd9af4..ebb937d5 100644 --- a/drafts/arcalinea-tx-expiry/draft.rst +++ b/drafts/arcalinea-tx-expiry/draft.rst @@ -1,12 +1,12 @@ -**Title:** Transaction Expiry +:: -**Author:** Jay Graber + ZIP: 203 + Title: Transaction Expiry + Author: Jay Graber + Category: Consensus + Created: 2018-01-09 + License: MIT -**Status:** Active - -**Category:** Standards - -**Created:** 2018-01-09 Abstract =========== @@ -16,11 +16,13 @@ This is an Standards ZIP describing a new consensus rule to set an expiration ti Motivation =========== -Transactions that have insufficient fees are often not mined. This indeterminism is a source of confusion for users and wallets. Allowing transactions to set a block height after which it expires from the mempool would provide certainty around how long a transaction has to confirm before it is rejected by the network and must be re-sent. +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. -Advantages include optimizing mempool performance by removing transactions unlikely to 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. +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. -If the expiry is block height N, it means the transaction must have either: 1. have been included in N-1, or 2. be included in block N. N+1 will be too late, and the transaction will be removed from the mempool. +If the expiry is at block height N, then the transaction must be included in block N or earlier. Block N+1 will be too late, and the transaction will be removed from the mempool. + +The new consensus rule will enforce that the transaction will not be considered valid if included in block of height greater than N, and blocks that include transactions which have expired will not be considered valid. Specification =============== @@ -53,14 +55,14 @@ With the addition of this feature, zero-confirmation transactions with an expira Wallet should notify user of expired transactions that must be re-sent. See "Notify" section below. -Wallet should notify user when building on a transaction with zero confirmations and an expiry blockheight set. Message TBD. - RPC ----- -To use: -To make changes to the sendtoaddress and z_sendmany commands backwards compatible for future changes, keyword arguments should be accepted by the RPC interface. Since this is not consensus critical behavior, it can be added in a future release. For Overwinter, tx expiry will be set to a default that can be overridden by a flag `txexpirydefault` set in the config file. --txexpirydefault= set default for tx expiry +To make changes to the sendtoaddress and z_sendmany commands backwards compatible for future changes, keyword arguments should be accepted by the RPC interface. + +For Overwinter, tx expiry will be set to a default that can be overridden by a flag `txexpirydelta` set in the config file. + +-txexpirydelta= set the number of blocks after which a transaction that has not been mined will become invalid To view: listtransactions has a new filter attribute, showing expired transactions only: @@ -74,3 +76,8 @@ Config Default will be user configurable with flag `txblockexpirydelta` `--txblockexpirydelta=100` + +Deployment +------------ + +This feature will be deployed with Overwinter. The activation blockheight proposal is in [ZIP 201](https://github.com/zcash/zips/blob/master/zip-0201.rst) From 4805b365cac0c106067962a3177e272d04e96e23 Mon Sep 17 00:00:00 2001 From: Jay Graber Date: Fri, 2 Mar 2018 15:10:36 -0800 Subject: [PATCH 15/15] Changes --- drafts/arcalinea-tx-expiry/draft.rst | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/drafts/arcalinea-tx-expiry/draft.rst b/drafts/arcalinea-tx-expiry/draft.rst index ebb937d5..8dd7c9da 100644 --- a/drafts/arcalinea-tx-expiry/draft.rst +++ b/drafts/arcalinea-tx-expiry/draft.rst @@ -11,7 +11,7 @@ Abstract =========== -This is an Standards ZIP describing a new consensus rule to set an expiration time for transactions that are not mined to be removed from the mempool. +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. Motivation =========== @@ -22,38 +22,38 @@ Advantages include optimizing mempool performance by removing transactions that If the expiry is at block height N, then the transaction must be included in block N or earlier. Block N+1 will be too late, and the transaction will be removed from the mempool. -The new consensus rule will enforce that the transaction will not be considered valid if included in block of height greater than N, and blocks that include transactions which have expired will not be considered valid. +The new consensus rule will enforce that the transaction will not be considered valid if included in block of height greater than N, and blocks that include expired transactions will not be considered valid. Specification =============== -Transactions will have a new field, nExpiryHeight, which will set the block height after which transactions will be removed from the mempool if they have not been mined. +Transactions will have a new field, ``nExpiryHeight``, which will set the block height after which transactions will be removed from the mempool if they have not been mined. -The data type for nExpiryHeight will be uint32_t. If used in combination with nLockTime, both nLockTime and nExpiryHeight must be block heights. nExpiryHeight will never be a UNIX timestamp, unlike nLockTime values, and thus the maximum expiry height will be 500000000. +The data type for ``nExpiryHeight`` will be ``uint32_t``. If used in combination with ``nLockTime``, both ``nLockTime`` and ``nExpiryHeight`` must be block heights. ``nExpiryHeight`` will never be a UNIX timestamp, unlike ``nLockTime`` values, and thus the maximum expiry height will be 499999999. 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. -```` +``` "txid": "17561b98cc77cd5a984bb959203e073b5f33cf14cbce90eb32b95ae2c796723f", "version": 3, "locktime": 2089, "expiryheight": 3539, ``` -Default: TBD. Current proposal is 24 blocks, or about 1 hour assuming 2.5 minute block times. Can add a config option to set user's default. +Default: 20 blocks, or about 1 hour assuming 2.5 minute block times. A configuration option can be used to set the user's default. Minimum: No minimum Maximum: 499999999, about 380 years -No limit: To set no limit on transactions (so that they do not expire), nExpiryHeight should be set to 0. -Coinbase: nExpiryHeight on coinbase transactions is ignored, and is set to 0 by convention. +No limit: To set no limit on transactions (so that they do not expire), ``nExpiryHeight`` should be set to 0. +Coinbase: ``nExpiryHeight`` on coinbase transactions is ignored, and is set to 0 by convention. -Every time a transaction expires and should be removed from the mempool, so should all its dependent transactions. +Every time a transaction expires and should be removed from the mempool, so should all of its dependent transactions. Wallet behavior and UI ----------------------- 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. -Wallet should notify user of expired transactions that must be re-sent. See "Notify" section below. +Wallet should notify the user of expired transactions that must be re-sent. RPC -----