Vendor bitbox02 library

[achow101]

This brings the bitbox02 implementation in line with the implementations of the other hardware wallets as we include copies of their respective libraries in our source tree rather than just including them as a dependency. Alternative to #677

Also an issue with bitbox02 in the GUI is fixed.

Fixes #675

[achow101]

cc @benma

[benma]

Thanks. Looking at this now, I see you need to add the deps of the bitbox02 deps manually. This is an obvious disadvantage - if the bitbox02 lib gets new deps or bumps its dep versions to fix issues, this would have to be done here as well.

What is the problem exactly with using a regular dep? The linked issue is not convincing to me:

For a user that does not have a bitbox device, this is an extra dependency and extra code that is not needed.

But the code is still there, just vendored.

In the end I think a regular dep is preferable for the above reason, and should also be easier to manage. If you have other reasons to vendor, please let me know and proceed anyway. In that case it would be helpful to add the commands you used to vendor in the commit msg (or in the README) so that updating it to newer versions is easier.

[achow101]

The vendoring of device libraries is done for two reasons: 1) to remove unnecessary dependencies and code, and 2) to lock in the exact API that we are using. We have had issues in the past where differing library versions on a user's system have resulted in incompatibiliies and unexpected behavior. Vendoring the device library lets us ensure that the version of the library that ends up being used is the one that we have tested against, and it gives us better control over dependencies.

We mainly want to avoid letting external dependencies pull in even more dependencies that completely blow up our dependency stack which makes it hard to actually know what code is being run and if any of it is malicious.

Honestly, I'm not particularly thrilled by the dependencies that supporting bitbox02 and some other recent devices have forced us to add.

[benma]

Sounds reasonable 👍 Thanks for elaborating.

If it helps: noiseprotocol is used to encrypt the communication (see http://www.noiseprotocol.org/), protobuf is used to encode/decode the API messages to/from the BitBox02. semver is used to enable/disable support for features depending on the firmware version.

[prusnak]

Honestly, I'm not particularly thrilled by the dependencies that supporting bitbox02 and some other recent devices have forced us to add.

Btw, you can drop the protobuf dependency if you rewrite the bitbox02 code to use https://github.com/bitcoin-core/HWI/blob/master/hwilib/devices/trezorlib/protobuf.py