Apply various suggestions from review

Co-authored-by: Daira-Emma Hopwood <daira@jacaranda.org>
This commit is contained in:
Jack Grigg 2024-07-16 04:35:19 +01:00
parent 0d33eee0a2
commit 841119dea9
1 changed files with 21 additions and 7 deletions

View File

@ -155,7 +155,18 @@ transactions to other transactions.
The remainder of this specification assumes a wallet that follows all of these
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
@ -177,7 +188,7 @@ Rationale for the given numbers of confirmations
''''''''''''''''''''''''''''''''''''''''''''''''
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
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
the pending or total balance, but not in the confirmed-spendable
balance;
* if the wallet is not synchronized, the confirmed-spendable balance
will be zero.
* if the wallet has not synchronized at least the nullifier set to the
chain tip, the confirmed-spendable balance will be zero.
If auto-shielding is disabled, the wallet MAY report shielded and
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
balances (and potentially, for expert users, separate shielded balances
per pool) can constitute useful information. If auto-shielding is enabled
balances can constitute useful information. If auto-shielding is enabled
then the wallet can and will automatically spend transparent TXOs in
order to shield them, and so transparent TXOs need to be presented as
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
visibility into the operation of auto-shielding, opportunistic shielding,
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)
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)
@ -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>`_
.. [#zip-0203] `ZIP 203: Transaction Expiry <zip-0203.rst>`_
.. [#zip-0317] `ZIP 317: Proportional Transfer Fee Mechanism <zip-0317.rst>`_