Fixes the Trezor T multisig tests. Part of this requires fixes to displayaddress and the Trezor implementation. The majority of the changes here are to make the multisig derivation paths conform to Trezor's purpose 48.

Instead of having display_address handle both single sig and multisig address display, it is refactored into display_singlesig_address to display single sig addresses, and display_multisig_address to display multisig addresses. Additionally the redeem_script parameter is removed as descriptors provide everything we need.

Supersedes #416. I think this approach is nicer to work with.

Refactors the display_address method in each device to split up display address by path and display address by descriptor. Instead of having both be done by the same function, we now have display_address_path and display_address_descriptor for each. This PR includes some changes to Descriptor in order to support this.

Builds on #415 for the address type changes done there.

@benma Just for your information, #416 may end up being closed and a different approach taken. So It might be better for you to leave the display multisig address part for last. I'm still trying to work out a good API.

Thanks! I will get on this asap.

This is general pyproject.toml maintenance. Python 3.9 is the latest python version, so we should allow it. Ideally, we would not set a python version upper bound, but the pyside2 package sets a python version upper bound, so poetry requires us to also set that.

Additionally, the version number in the master branch was super out of date. 2.0.0-dev is more accurate - we are developing for 2.0.0 in master currently.

Lastly, all of the dependencies in poetry.lock are updated.

Sorry for taking so long to get to this.

I would like for this PR to be split up as there are some upcoming changes that are going to conflict with this, namely #415 and #416 which refactor display_address. Given my lack of familiarity with the BitBox02 implementation, I think it would be better for those parts of this PR to be based on those PRs and for other components that do not conflict to be in separate PRs to be merged soon.

Here are the PRs that I suggest this be split into:

• PSBT_GLOBAL_XPUB parsing:
  • 9cc1fd1615771ec0f53e0349cf32fc7164d37d9f PSBT: also parse and serialize PSBT_GLOBAL_XPUB
• Bitbox02 5.1.0 based on #421
  • c9c4d7540b4162f50c3fcf66321c1631f9c0cca5 bitbox02: update bitbox02 to 5.1.0
• BitBox02 Multisig signing
  • e9aa60063f3f64679564fdb6b6194d5fc0fe2b19 bitbox02: restructure signing code
  • 5916c300dd4b447d9d4191ea149b3c884e41b4ba bitbox02: implement multisig signing
  • Some of e689ed0d4ec9f29e26bce612ea54e60c4adb01f0 bitbox02: update docs
• BitBox02 multisig address display based on #416
  • 37ef0626c36031ea1c68d0999a8e70e207ef6228 bitbox02: implement multisig display_address()

1deefb0f2635a52e6f62acca9137c50097e71ee7 can be dropped if this is based on #416 because that removes the whole redeem script thing from multisig address display.

af619729f266bfaad443d0af60046feccdaa617f can be dropped since it is an unrelated formatting change.

f8f44a6e68bd797ce4eb79b9bd607ed587180e18 could be dropped or squashed into another commit.

This particular issue is fixed in this commit:

https://github.com/bitcoin-core/HWI/pull/407/commits/c9c4d7540b4162f50c3fcf66321c1631f9c0cca5

I could extract it into a separate PR if you want.

BitBox02 is failing the type checker: https://cirrus-ci.com/task/6500295159054336

cc @benma

Closes #386

Seems like we should keep Keepkey support.

This is general pyproject.toml maintenance. Python 3.9 is the latest python version, so we should allow it. Ideally, we would not set a python version upper bound, but the pyside2 package sets a python version upper bound, so poetry requires us to also set that.

Additionally, the version number in the master branch was super out of date. 2.0.0-dev is more accurate - we are developing for 2.0.0 in master currently.

Lastly, all of the dependencies in poetry.lock are updated.

Doing any command which requires updating dependencies (i.e. poetry update or poetry lock) causes poetry to hang. It seems like it is hanging on resolving the dependencies for the pyside2 package.

Edit: This originally said bitbox02 but I did some debugging and it seems to be pyside2 that's causing the problem.

Apparently I have a caching problem. Clearing some poetry http cache fixes this.

I am using keepkey with Specter and Sparrow Instead of removing Keepkey I would recommend to copy the trezorlib implementation and just make it Keepkey specific similar as Electrum has done (so Keepkey would be implemented as a separate device instead of as a Trezor device. And yes this will mean that there's a lot of duplicated code)

Maybe @keepkeyjoncan help/assist you through the work of patching trezorlib to work with the keepkey every time it is updated.

Oops, I completely forgot about this PR. I don't even remember making it, so let's call it up for grabs.

Doing any command which requires updating dependencies (i.e. poetry update or poetry lock) causes poetry to hang. It seems like it is hanging on resolving the dependencies for the bitbox02 package.

PyInstaller was including a bunch of system libraries that we don't need. Removing them makes the final build smaller and lets us not have to worry about them when it comes to reproducibility. These libraries are not used by HWI but are imported by python built-ins that we aren't using. These all have handling for the libraries not being there so it is fine to exclude them.

The libraries being excluded are:

• libz
• libbz2
• libzma
• libreadline

libz (zlib) has to be handled more specially when python is being built during the docker container setup. The python compilation will include it if it detects it, so we apply an additional patch to CPython for it to not do that.

Adds additional version pinning so that builds are more reproducible. Poetry for the build also has a fixed version number. Cython is now a dependency so that hidapi is built reproducibly.

Fixes #303

Ok for 2.0 this is probably fine.

On Sat, Jan 23, 2021, 7:28 AM Andrew Chow notifications@github.com wrote:

Could we put it behind a deprecation flag or something for a release cycle? If no complaints show up, remove?

Since I am trying to do SemVer correctly, that seems like it would require 2 major releases to do that since it is ostensibly an API breaking change. The big promise of 2.0 is that we can break the API.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/bitcoin-core/HWI/pull/418#issuecomment-765741844, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABMAFUZQB3GTPGCNNWGPVBTS3IC2JANCNFSM4WLHWRDA .

This is helpful when debugging a specific device module import/dependency issue.

Closing due to lack of activity. marking as up for grabs

Closing due to lack of activity.

Could we put it behind a deprecation flag or something for a release cycle? If no complaints show up, remove?

Since I am trying to do SemVer correctly, that seems like it would require 2 major releases to do that since it is ostensibly an API breaking change. The big promise of 2.0 is that we can break the API.

Looks like all the default paths for bitcoind and various simulators are off for Travis. Poking around to see if I can get to more meaningful travis failures/results.