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 1) "We are offline and cannot expand the validity period." 94 2) "The payment service provider does not offer longer 95 validity periods." 96 97 ..note:: 98 99 This should prevent us from getting into trouble if 100 e-cash is lost anyway. 101 102 103 Definition of Done 104 ================== 105 106 * Implemented in wallet-core 107 * Changes to interactions for signalling warnings to GUIs 108 * dev-experiments exist to trigger special alerts to users 109 * GUIs have been designed and tested 110 111 112 Alternatives 113 ============ 114 115 The wallet currently implements simple rules for auto-refresh: 116 117 1. After 75% of a denomination's "deposit lifespan" has passed, 118 we do "auto-refresh check" for all coins of the exchange 119 120 2. During this auto-refresh check, all coins that are >50% into 121 their deposit lifespan are auto-refreshed. 122 123 This is risky as it does not consider absolute lifespans or user 124 behavior. 125 126 127 Drawbacks 128 ========= 129 130 * This approach does not (yet) consider user behavior. We could 131 theoretically learn from that. 132 133 134 135 Discussion / Q&A 136 ================ 137 138 (This should be filled in with results from discussions on mailing lists / personal communication.)