mirror of https://github.com/zcash/zips.git
ZIP 203: line wrapping and formatting.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood
parent
aec18d6aa8
commit
e433e8ae4e
88
zip-0203.rst
88
zip-0203.rst
|
|
@ -11,29 +11,48 @@
|
|||
|
||||
|
||||
Abstract
|
||||
===========
|
||||
========
|
||||
|
||||
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.
|
||||
|
||||
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
|
||||
===========
|
||||
==========
|
||||
|
||||
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.
|
||||
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 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.
|
||||
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 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.
|
||||
If the expiry is at block height :math:`N`, then the transaction must be included in block
|
||||
:math:`N` or earlier. Block :math:`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 :math:`N`, and blocks that include expired
|
||||
transactions 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 499999999.
|
||||
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.
|
||||
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.
|
||||
|
||||
::
|
||||
|
||||
|
|
@ -42,29 +61,43 @@ For the example below, the last block that the transaction below could possibly
|
|||
"locktime": 2089,
|
||||
"expiryheight": 3539,
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
Every time a transaction expires and should be removed from the mempool, so should all
|
||||
of 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.
|
||||
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 the user of expired transactions that must be re-sent.
|
||||
Wallet should notify the user of expired transactions that must be re-sent.
|
||||
|
||||
RPC
|
||||
-----
|
||||
---
|
||||
|
||||
To make changes to the sendtoaddress and z_sendmany commands backwards compatible for future changes, keyword arguments should be accepted by the RPC interface.
|
||||
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.
|
||||
For Overwinter, transaction 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
|
||||
``-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::
|
||||
|
||||
|
|
@ -73,16 +106,17 @@ To view: `listtransactions` has a new filter attribute, showing expired transact
|
|||
WalletTxToJSON shows a boolean expired true/false.
|
||||
|
||||
Config
|
||||
-------
|
||||
------
|
||||
|
||||
The default will be user-configurable with the option `txexpirydelta`.
|
||||
|
||||
`--txexpirydelta=100`
|
||||
|
||||
Deployment
|
||||
------------
|
||||
----------
|
||||
|
||||
This feature will be deployed with Overwinter. The activation blockheight proposal is in [#zip-0201]_.
|
||||
This feature will be deployed with Overwinter. The activation blockheight proposal is in
|
||||
[#zip-0201]_.
|
||||
|
||||
|
||||
Reference Implementation
|
||||
|
|
|
|||
Loading…
Reference in New Issue