Closed jlopp closed 5 years ago
I'm assuming that MINIMUM_FIRMWARE_VERSION is set based upon new API calls / features that are added to the library that are only supported after a certain firmware version.
This assumption is wrong. We try to keep the API compatible so new features rarely/never break older firmware. This minimum version is usually the last firmware version that included a critical security update. In general, we want our users to always have up-to-date Trezor.
OK, good to know - I totally understand the motivation. I just want you to keep in mind that there are edge cases for which a user may be running old firmware and updating it is not an option. I'm reaching out to other projects that make use of this library to inform them as well so that we can come up with workarounds for this edge case.
I was just testing our open source "sovereign recovery" process for Casa 3-of-5 multisig users and noticed that it no longer works for me due to the "outdated firmware" error. I'm getting this error both in Electrum and in Bitcoin Core HWI while trying to use a Model T running firmware version 2.0.7 while the MINIMUM_FIRMWARE_VERSION in the trezor python library being used is 2.1.0
Because Casa's multisig key management app is seedless (users don't store the seed phrases for devices) it's likely that their device firmware may be out of date. This is because firmware updates sometimes wipe the seed from the device, thus requiring the user to perform a key rotation. Also, hardware devices are geographically distributed and may not be used for long periods of time.
Long story short, if a catastrophic event were to befall Casa and our users need to recover funds without using our servers to coordinate signing, they'll need to be able to recreate their wallets using their hardware devices with whatever the currently running firmware version is, and upgrading the firmware may not be an option.
I'm assuming that MINIMUM_FIRMWARE_VERSION is set based upon new API calls / features that are added to the library that are only supported after a certain firmware version. Is there any way that you can improve the backward compatibility of the library? Perhaps this check should be performed at each API call granularity rather than the entire device granularity?
The reason I suspect this may work better is because I've been able to comment out the version check in the library and still successfully make calls to my Model T that is supposedly running an outdated firmware version.