[taler-docs] branch master updated: move to alternatives

[gnunet]

This is an automated email from the git hooks/post-receive script.

grothoff pushed a commit to branch master
in repository docs.

The following commit(s) were added to refs/heads/master by this push:
     new 1c46588  move to alternatives
1c46588 is described below

commit 1c465883cb1e764b5a3167f254c6ab15da2262f9
Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Sat Apr 8 17:56:00 2023 +0200

    move to alternatives
---
 .../037-wallet-transactions-lifecycle.rst          | 47 +++++++++++++---------
 1 file changed, 27 insertions(+), 20 deletions(-)

diff --git a/design-documents/037-wallet-transactions-lifecycle.rst 
b/design-documents/037-wallet-transactions-lifecycle.rst
index 64ec242..ec1b8cb 100644
--- a/design-documents/037-wallet-transactions-lifecycle.rst
+++ b/design-documents/037-wallet-transactions-lifecycle.rst
@@ -152,18 +152,6 @@ Part of a withdrawal process or peer-to-peer push credit.
 Transaction Type: Withdrawal
 ----------------------------
 
-XXX: What if available denominations change?  Does this require a user 
re-approval if fees
-change due to this?
-CG: I think the answer can be "no", for two reasons: the wallet MUST pick 
denominations
-to withdraw with the "most long-term" withdraw window (i.e. active 
denominations that have
-the longest available withdraw durations). So in 99.9% of all cases, this will 
just succeed
-as a sane exchange will have a reasonable duration overlap, and in the 0.1% of 
cases it's
-really the user's fault for going offline in the middle of the operation. 
Plus, even in those
-0.1% of cases, it is highly unlikely that the fee would actually change: again 
99% of key
-rotations can be expected to be there to rotate the key, and not to adjust the 
withdraw fee.
-And in the 1:1M case that the fee does *increase*, it's again unlikely to 
matter much to the
-user. So special-casing this and testing this is IMO just not worth it.
-
 * ``initial(bank-register-reserve)``
 
   Initial state for bank-integrated withdrawals.  The wallet submits the 
reserve public key
@@ -405,14 +393,6 @@ Transaction Type: Tip
 Transaction Type: Deposit
 -------------------------
 
-XXX: Handle expired/invalid coins in the coin selection. Does this require 
user approval if fees changed?
-
-CG: Again, expired coins should never happen. If deposit fees *increase* due
-to a double-spend detection during payment, we might want to have an
-_optional_ dialog ("Balance reduced by X as wallet state was not up-to-date
-(did you restore from backup?).  Consequently, the fees for this transactions
-increased from Y to Z.  [Abort] [Continue] + checkbox: [X] Do not ask again."
-
 * ``initial``
 
   Deposit is created, effective amount is removed from balance
@@ -648,6 +628,33 @@ Alternatives
   terminology for actions (and thus button labels) is likely more helpful for
   the user experience.
 
+* We could require user re-approval if fees changed when the available
+  denominations change during a *withdraw*.  This would require a different
+  state machine on withdraw. We believe the answer can be "no", for two
+  reasons: the wallet MUST pick denominations to withdraw with the "most
+  long-term" withdraw window (i.e. active denominations that have the longest
+  available withdraw durations). So in virtually all normal cases, this will
+  just succeed as a sane exchange will have a reasonable duration overlap, and
+  in the very few cases it's really the user's fault for going offline in the
+  middle of the operation. Plus, even in those few cases, it is highly
+  unlikely that the fee would actually change: again most key rotations can be
+  expected to be there to rotate the key, and not to adjust the withdraw fee.
+  And in the extremely rare case that the user went offline and in the
+  meantime the fees did *increase*, it's again unlikely to matter much to the
+  user. So special-casing this and testing this is probably not worth it.
+
+* We could require user re-approval if due to expired/invalid coins the coin
+  selection (and thus fees) changes during a *deposit*.  Again, expired coins
+  should virtually never happen unless a user goes offline for a long time in
+  the middle of a purchase (which would be very strange). If deposit fees
+  *increase* due to a double-spend detection during payment, we might want to
+  have an *optional* dialog ("Balance reduced by X as wallet state was not
+  up-to-date (did you restore from backup?).  Consequently, the fees for this
+  transactions increased from Y to Z.  [Abort] [Continue] + checkbox: [X] Do
+  not ask again."). Probably at best a post-1.0 feature.
+
+
+
 
 Drawbacks
 =========

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.