2fb0dd066f
* Timelock Recovery Extension * Timelock Recovery Extension tests * Use fee_policy instead of fee_est Following3f327eea07* making tx with base_tx Followingab14c3e138* move plugin metadata from __init__.py to manifest.json * removing json large indentation * timelock recovery icon * timelock recovery plugin: fix typos * timelock recovery plugin: use menu instead of status bar. The status bar should be used for displaying status. For example, hardware wallet plugins use it because their connection status is changing and needs to be displayed. * timelock recovery plugin: ask for password only once * timelock recovery plugin: ask whether to create cancellation tx in the initial window * remove unnecessary code. (calling run_hook from a plugin does not make sense) * show alert and cancellation address at the end. skip unnecessary dialog * timelock recovery plugin: do not show transactions one by one. Set the fee policy in the first dialog, and use the same fee policy for all tx. We could add 3 sliders to this dialog, if different fees are needed, but I think this really isn't really necessary. * simplify default_wallet for tests All the lightning-related stuff is irrelevant for this plugin. Also use a different destination address for the test recovery-plan (an address that does not belong to the same wallet). * Fee selection should be above fee calculation also show fee calculation result with "fee: " label. * hide Sign and Broadcast buttons during view * recalculate cancellation transaction The checkbox could be clicked after the fee rate has been set. Calling update_transactions() may seem inefficient, but it's the simplest way to avoid such edge-cases. Also set the context's cancellation transaction to None when the checkbox is unset. * use context.cancellation_tx instead of checkbox value context.cancellation_tx will be None iff the checkbox was unset * hide cancellation address if not used * init monospace font correctly * timelock recovery plugin: add input info at signing time. Fixes trezor exception: 'Missing previous tx' * timelock recovery: remove unused parameters * avoid saving the tx in a separate var fixing the assertions * avoid caching recovery & cancellation inputs * timelock recovery: separate help window from agreement. move agreement at the end of the flow, rephrase it * do not cache alert_tx_outputs * do not crash when not enough funds not enough funds can happen when multiple addresses are specified in payto_e, with an amount larger than the wallet has - so we set the payto_e color to red. It can also happen when the user selects a really high fee, but this is not common in a "recovery" wallet with significant funds. * If files not saved - ask before closing * move the checkbox above the save buttons people read the text from top to bottom and may not understand why the buttons are disabled --------- Co-authored-by: f321x <f321x@tutamail.com> Co-authored-by: ThomasV <thomasv@electrum.org>
Plugin rules: * The plugin system of Electrum is designed to allow the development of new features without increasing the core code of Electrum. * Electrum is written in pure python. if you want to add a feature that requires non-python libraries, then it must be submitted as a plugin. If the feature you want to add requires communication with a remote server (not an Electrum server), then it should be a plugin as well. If the feature you want to add introduces new dependencies in the code, then it should probably be a plugin. * We expect plugin developers to maintain their plugin code. However, once a plugin is merged in Electrum, we will have to maintain it too, because changes in the Electrum code often require updates in the plugin code. Therefore, plugins have to be easy to maintain. If we believe that a plugin will create too much maintenance work in the future, it will be rejected. * Plugins should be compatible with Electrum's conventions. If your plugin does not fit with Electrum's architecture, or if we believe that it will create too much maintenance work, it will not be accepted. In particular, do not duplicate existing Electrum code in your plugin. * We may decide to remove a plugin after it has been merged in Electrum. For this reason, a plugin must be easily removable, without putting at risk the user's bitcoins. If we feel that a plugin cannot be removed without threatening users who rely on it, we will not merge it.