commit 1c465883cb1e764b5a3167f254c6ab15da2262f9
parent 3fce863ce0a65712cf4c91d7d4fc099f679eb6c0
Author: Christian Grothoff <christian@grothoff.org>
Date: Sat, 8 Apr 2023 17:56:00 +0200
move to alternatives
Diffstat:
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
@@ -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
=========
