071-auto-refresh.rst (4185B)
1 DD 71: Auto-refresh 2 ################### 3 4 Summary 5 ======= 6 7 This document describes when the wallet should automatically refresh 8 non-dirty coins. 9 10 11 Motivation 12 ========== 13 14 The wallet must refresh non-dirty coins before they expire, least the 15 user looses the money. However, this should not be done too early to 16 avoid refresh fees and/or excessive load on the exchange. On the other 17 hand, we need to be careful to not hold off for too long and risk 18 the wallet not going online before the expiration time. 19 20 We note that there obviously is no perfect solution, as at least in 21 principle the user could always not restart the wallet until the 22 expiration time. 23 24 25 Requirements 26 ============ 27 28 * Do not loose funds under most conditions 29 * Do not cause clearly avoidable refresh operations 30 * Try to educate the user if they are about to get into trouble 31 * Independently of any specific approach, the wallet 32 MUST spend those coins first that are earliest to 33 their expiration time within their equivalence class 34 as that is always the best way to avoid expiration. 35 * While lifetimes of denominations are often identical, 36 that may not always be the case. Theoretically, an 37 exchange could significantly increase or decrease the 38 deposit period at any time. The solution should 39 take this into consideration. 40 41 42 Proposed Solution 43 ================= 44 45 1. For each denomination, consider if a refresh would 46 lengthen the expiration date by more than a factor 47 of four (4x), that is if the deposit expiration time 48 of the denomination(s) we could currently withdraw 49 is more than 4x as long as what remains for the 50 denomination. If so, refresh 51 all coins of that denomination. 52 53 54 ..note:: 55 56 This basically suggests that a refresh 57 would have a significant positive **impact**. 58 59 2. For each denomination, consider if the remaining 60 deposit period is less than **6** months, if the 61 refresh fee would be zero, and if after refreshing 62 the deposit expiration time would exceed **12** months, 63 and if we are not on battery power. If so, refresh 64 all coins of that denomination. 65 66 ..note:: 67 68 This is again a significant impact, and it is basically 69 gratis for the user. 70 71 3. For each denomination, consider if the remaining 72 deposit period is less than **3** months, and if 73 after refreshing the deposit expiration time would 74 be larger. If so, refresh all coins of that denomination. 75 If afterwards the expiration time exceeds **12** months, 76 show the user a warning: 77 78 "This wallet was offline for too long. Make sure to 79 start it at least every **3 months** to avoid the 80 risk of loosing funds to expiration." 81 82 ..note:: 83 84 This is basically a last-minute effort (unless we have 85 an exchange with extremely short expiration periods). 86 We do not like getting into this situation, so it is 87 time to educate the user. 88 89 4. Explicitly show a warning in the balances list of 90 the respective currency if the remaining deposit 91 period for any coin drops below 90 days. 92 Distinguish in the warning key causes: 93 94 1. "We are offline and cannot expand the validity period." 95 2. "The payment service provider does not offer longer 96 validity periods." 97 98 ..note:: 99 100 This should prevent us from getting into trouble if 101 e-cash is lost anyway. 102 103 104 Definition of Done 105 ================== 106 107 * Implemented in wallet-core 108 * Changes to interactions for signalling warnings to GUIs 109 * dev-experiments exist to trigger special alerts to users 110 * GUIs have been designed and tested 111 112 113 Alternatives 114 ============ 115 116 The wallet currently implements simple rules for auto-refresh: 117 118 1. After 75% of a denomination's "deposit lifespan" has passed, 119 we do "auto-refresh check" for all coins of the exchange 120 121 2. During this auto-refresh check, all coins that are >50% into 122 their deposit lifespan are auto-refreshed. 123 124 This is risky as it does not consider absolute lifespans or user 125 behavior. 126 127 128 Drawbacks 129 ========= 130 131 * This approach does not (yet) consider user behavior. We could 132 theoretically learn from that. 133 134 135 136 Discussion / Q&A 137 ================ 138 139 (This should be filled in with results from discussions on mailing lists / personal communication.)