This makes it possible to bump the managed bitcoind version used
when installing a new Liana wallet.
The GUI will look for the most recent managed bitcoind version
available when starting bitcoind so that existing wallets
with a previous managed bitcoind version will not be affected.
4be74ad496692d371adffcc1b3c868ef6a01cb52 refac hw module and add bitbox support (edouard)
Pull request description:
- Add bitbox02 as possible signer to liana-gui
- Introduce global_settings.json in datadir to keep the bitbox noise config.
ACKs for top commit:
edouardparis:
Self-ACK 4be74ad496692d371adffcc1b3c868ef6a01cb52
Tree-SHA512: e0615e1903baa7faecc25db717f49ed71c23a6afcec607c41ac2045cfb2cfa9a9aa3d3452cc952aeaf72a735d670c56dbf19b239c8d665466a2ecb09fbe222c5
For transactions that have been broadcast, the feerate is calculated
using the transaction's actual size. For PSBTs, the feerate is
calculated using the max satisfaction size for all inputs, whether
they have been signed or not.
9895b493f1d79ae8fc5a1591ef455ccda2d81ccd gui: trim text input strings (jp1ac4)
d3f2931375ff95c201a60164bf1015f18c6e87ce gui: remove unused file (jp1ac4)
Pull request description:
This is to resolve#323.
Following suggestions in #323, I've added a new `TrimmedString` struct that takes a string and applies `trim()`. This type is then used as `form::Value<TrimmedString>` to ensure text inputs are trimmed.
I'm creating this PR as draft to check if this is the right approach before applying the change to other inputs.
I've also removed a view file that seems to have been created accidentally.
ACKs for top commit:
edouardparis:
ACK 9895b493f1d79ae8fc5a1591ef455ccda2d81ccd
Tree-SHA512: 76c7f28ed2d0b6b6b76658a9368b918b0b211e2fabd72ac5d19c13adcbb2d3645b78680a8849f235ee58620fbe8df440ef8354f2d50d39601879bb7727465335
f771e674faccf150a5210b3abe829d443619c3e6 gui(installer): restrict clicking previous on final step (jp1ac4)
45f91216d5d0991d7aebde8d4c8bc99edaf5521a gui(installer): remove unused fields from final step (jp1ac4)
03c2bd76b8c6c1b721014afb37da7732ddfeb0cd gui(installer): install and start automatically on final step (jp1ac4)
Pull request description:
This is to resolve#679.
The following changes have been made:
- Change title of final step to "Finalize installation"
- Install and load wallet automatically when reaching final step
- Remove fields from `Final` step that are no longer used
This is how the page looks when installing:
The following is only shown for ~1 sec once wallet has been installed and before loading wallet:
ACKs for top commit:
edouardparis:
ACK f771e674faccf150a5210b3abe829d443619c3e6
Tree-SHA512: b5360c77a13e4028331e4072246f1c897aa6fe61b0c8697b33d5c91ed460e55fe76b8808f4779db2b2f0322e27433e5dbb72fd0210cbf77f28a270bd82ea2558
eebf0c20350554f422a028076a460b19f88a7c34 contrib: adapt GUIX build for iced_futures patch (edouard)
df849ba960ace67615a452970ffd2f323a53974e gui: use patch for iced_futures (edouard)
Pull request description:
from #685
ACKs for top commit:
darosior:
ACK eebf0c20350554f422a028076a460b19f88a7c34 -- that's a clean backport of #685 (which i ack'd) and of #687 (which i authored).
Tree-SHA512: e80777417dad0301ce6b9762b2fac02a684e3ce312ad77509e5f2457bfdd11f93d46108fe7bed451eeacf7cc0f3703a8cfa8e18e2dda8f193e704a44c42d019a
76bb74371f7d33603ac0864b9ecea014a3cc0cda gui: installer: more robust poll for cookie file at bitcoind startup (Antoine Poinsot)
Pull request description:
We would formerly wait a definite number of seconds for the cookie file to appear. But this approach presents a fundamental issue: how long is enough before we can be reasonably sure bitcoind will never start?
For instance on mainnet the checks performed at startup could take more than the 3 seconds we would previously wait for. If it does we would have incorrectly errored and let bitcoind run in the background.
Instead, assume bitcoind would exit if it errors. Until it does so, continue polling for the cookie file. This approach also presents drawbacks (for instance what if bitcoind is performing a very long operation before creating the cookie file?), but the former approach wouldn't be an acceptable solution in this case either. And the new one is preferable as its failure scenario seems much less probable.
ACKs for top commit:
edouardparis:
ACK 76bb74371f7d33603ac0864b9ecea014a3cc0cda
Tree-SHA512: a0d4af1cadbea99c4c9f5ca6b7e642a79e97c7a35e829704144be5edb84c9c398872b7fbaab3af73600589194512747ac8da9cb7787a362bde3c6ef797f4ec29
We would formerly wait a definite number of seconds for the cookie file
to appear. But this approach presents a fundamental issue: how long is
enough before we can be reasonably sure bitcoind will never start?
For instance on mainnet the checks performed at startup could take more
than the 3 seconds we would previously wait for. If it does we would
have incorrectly errored and let bitcoind run in the background.
Instead, assume bitcoind would exit if it errors. Until it does so,
continue polling for the cookie file. This approach also presents
drawbacks (for instance what if bitcoind is performing a very long
operation before creating the cookie file?), but the former approach
wouldn't be an acceptable solution in this case either. And the new one
is preferable as its failure scenario seems much less probable.
