mirror of https://github.com/zcash/zips.git
Apply various suggestions from review
Co-authored-by: Daira-Emma Hopwood <daira@jacaranda.org>
This commit is contained in:
parent
0d33eee0a2
commit
841119dea9
28
zip-0315.rst
28
zip-0315.rst
|
@ -155,7 +155,18 @@ transactions to other transactions.
|
||||||
The remainder of this specification assumes a wallet that follows all of these
|
The remainder of this specification assumes a wallet that follows all of these
|
||||||
recommendations, except where explicitly noted.
|
recommendations, except where explicitly noted.
|
||||||
|
|
||||||
A wallet MAY allow users to disable auto-shielding.
|
A wallet MAY allow users to disable auto-shielding, auto-migration,
|
||||||
|
and/or opportunistic migration. If it does so, this need not be via
|
||||||
|
three independent settings.
|
||||||
|
|
||||||
|
Automatic shielding and automatic/opportunistic migration SHOULD NOT be
|
||||||
|
applied to inputs where the cost of shielding or migrating them will
|
||||||
|
exceed their economic value. If these transactions are paying the
|
||||||
|
ZIP 317 conventional fee [#zip-0317]_, that will be the case if the
|
||||||
|
amount of the UTXO to be shielded/migrated exceeds the marginal
|
||||||
|
fee, and cannot be accommodated by an input that would be present
|
||||||
|
in any case due to padding of the number of inputs from a given
|
||||||
|
shielded pool.
|
||||||
|
|
||||||
|
|
||||||
Trusted and untrusted TXOs
|
Trusted and untrusted TXOs
|
||||||
|
@ -177,7 +188,7 @@ Rationale for the given numbers of confirmations
|
||||||
''''''''''''''''''''''''''''''''''''''''''''''''
|
''''''''''''''''''''''''''''''''''''''''''''''''
|
||||||
|
|
||||||
The rationale for choosing three confirmations for trusted TXOs is that
|
The rationale for choosing three confirmations for trusted TXOs is that
|
||||||
empirically, reorgs are usually less than three blocks.
|
anecdotally, reorgs are usually less than three blocks.
|
||||||
|
|
||||||
The consequences of attempting to spend a trusted TXO may be less severe in the
|
The consequences of attempting to spend a trusted TXO may be less severe in the
|
||||||
case of a rollback than the consequences of attempting to spend an untrusted TXO.
|
case of a rollback than the consequences of attempting to spend an untrusted TXO.
|
||||||
|
@ -243,8 +254,8 @@ Note: the definition of "confirmed-spendable" above ensures that:
|
||||||
* if auto-shielding is enabled, transparent funds will be reported in
|
* if auto-shielding is enabled, transparent funds will be reported in
|
||||||
the pending or total balance, but not in the confirmed-spendable
|
the pending or total balance, but not in the confirmed-spendable
|
||||||
balance;
|
balance;
|
||||||
* if the wallet is not synchronized, the confirmed-spendable balance
|
* if the wallet has not synchronized at least the nullifier set to the
|
||||||
will be zero.
|
chain tip, the confirmed-spendable balance will be zero.
|
||||||
|
|
||||||
If auto-shielding is disabled, the wallet MAY report shielded and
|
If auto-shielding is disabled, the wallet MAY report shielded and
|
||||||
transparent balances separately. If it does so, it MUST make clear
|
transparent balances separately. If it does so, it MUST make clear
|
||||||
|
@ -255,12 +266,14 @@ Rationale for reporting of balances
|
||||||
'''''''''''''''''''''''''''''''''''
|
'''''''''''''''''''''''''''''''''''
|
||||||
|
|
||||||
If auto-shielding is disabled, then separate shielded and transparent
|
If auto-shielding is disabled, then separate shielded and transparent
|
||||||
balances (and potentially, for expert users, separate shielded balances
|
balances can constitute useful information. If auto-shielding is enabled
|
||||||
per pool) can constitute useful information. If auto-shielding is enabled
|
|
||||||
then the wallet can and will automatically spend transparent TXOs in
|
then the wallet can and will automatically spend transparent TXOs in
|
||||||
order to shield them, and so transparent TXOs need to be presented as
|
order to shield them, and so transparent TXOs need to be presented as
|
||||||
pending, not as part of the balance spendable by the user.
|
pending, not as part of the balance spendable by the user.
|
||||||
|
|
||||||
|
Potentially, for expert users, separate shielded balances per pool
|
||||||
|
could also be useful.
|
||||||
|
|
||||||
TODO: The specification of balance reporting is intended to give the user
|
TODO: The specification of balance reporting is intended to give the user
|
||||||
visibility into the operation of auto-shielding, opportunistic shielding,
|
visibility into the operation of auto-shielding, opportunistic shielding,
|
||||||
and pool migration/usage. (Does the spec satisfy this?)
|
and pool migration/usage. (Does the spec satisfy this?)
|
||||||
|
@ -327,7 +340,7 @@ Kinds of information leakage
|
||||||
|
|
||||||
* Transaction version (v4 or v5, as of NU5)
|
* Transaction version (v4 or v5, as of NU5)
|
||||||
|
|
||||||
SHOULD use v5 (unless you're spending Sprout funds).
|
It is RECOMMENDED to use v5 transactions unless Sprout funds are being spent.
|
||||||
|
|
||||||
* Lock time (rarely used; may be a distinguisher if it is)
|
* Lock time (rarely used; may be a distinguisher if it is)
|
||||||
|
|
||||||
|
@ -657,3 +670,4 @@ References
|
||||||
|
|
||||||
.. [#BCP14] `Information on BCP 14 — "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words" <https://www.rfc-editor.org/info/bcp14>`_
|
.. [#BCP14] `Information on BCP 14 — "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words" <https://www.rfc-editor.org/info/bcp14>`_
|
||||||
.. [#zip-0203] `ZIP 203: Transaction Expiry <zip-0203.rst>`_
|
.. [#zip-0203] `ZIP 203: Transaction Expiry <zip-0203.rst>`_
|
||||||
|
.. [#zip-0317] `ZIP 317: Proportional Transfer Fee Mechanism <zip-0317.rst>`_
|
||||||
|
|
Loading…
Reference in New Issue