ref(hwi): Move hwi out of bdk

[danielabrozzoni]

Fixes #872

Description

This commit moves the hardwaresigner outside of bdk and inside bdk_hwi

Notes to the reviewers

There are currently two issues with the code:

• TransactionSigner dictates that sign_transaction must return a SignerError - but being SignerError defined inside of bdk, we can't modify it to include an hwi specific error! I don't know how we could fix this (other than getting rid of the trait altogether :)); for now I just added a SignerError::Generic variant, lmk if you have better ideas!
• The hwi tests used the bdk utils to get a funded wallet for testing, which aren't available in bdk_hwi, which made me realize - maybe we should expose them so that we can use them across our crates, and also our users can use them to test their code?
  For now, I just left the test commented.

Changelog notice

• The old hardwaresigner module has been moved out of bdk and inside bdk_hwi.

Checklists

All Submissions:

• I've signed all my commits
• I followed the contribution guidelines
• I ran cargo fmt and cargo clippy before committing

New Features:

* [ ] I've added tests for the new feature

• I've added docs for the new feature

[nondiremanuel]

As per today's discussion in the Lib Team Call, this PR probably needs to be rebased after the ci fix of #1182

[ValuedMammal]

ACK

I also agree it would be nice to move some common bdk test utils to a shared crate - similar to #1171

[ValuedMammal]

would this work?

Suggested change

	SignerError::Generic(format!("While signing with hardware wallet: {}", e))
	SignerError::HWIError(e.to_string())

[danielabrozzoni]

In order for this to work, we would need to add the HWIError variant inside of bdk, which is not really desirable since it wouldn't be used inside bdk but in an outside crate.

[evanlinjin]

This PR moves harwaresigner into a separate crate, but the new crate still depends on bdk. Ideally, bdk_hwi should not depend on bdk. The best way to do this is to have the Signer traits in a separate crate as well - however, this is also non-ideal since those traits will most likely be scrapped in the future.

I would really love to have hwi as a separate crate. However, I don't think it makes sense to do it with the current state of Wallet.

Introducing SignerError::Generic is also non-ideal. Now the error variant for HWI is ambiguous.

In conclusion, I think we should try this again later down the line.

[danielabrozzoni]

Ideally, bdk_hwi should not depend on bdk

Why? We already have rust_hwi available if someone wants to use hardware wallets without using bdk. bdk_hwi is supposed to be for people that want to use hwi and bdk together, so I don't see why it shouldn't depend on bdk.

Introducing SignerError::Generic is also non-ideal. Now the error variant for HWI is ambiguous.

True, but at the moment everyone trying to implement the Signer trait in a crate outside of bdk encounters the same problem, so I think we should find a way to fix this anyways (without having to wait for a complete refactoring on the signer/wallet, since that will take a while). We could add either good docs to SignerError::Generic, create a SignerError::External (for external crates), or maybe we could refactor the trait to return a generic Box<dyn std::error::Error> (I haven't tested this so it might not be feasible)

I agree that this code is very suboptimal given the state of the Wallet, but we won't refactor the Wallet until bdk 2.0; do we want to leave hwi inside bdk, untested, until then?

[nondiremanuel]

@evanlinjin do you have any feedback on Daniela's last comment?

[notmandatory]

Please rebase now that #1183 has been merged.

[danielabrozzoni]

Done, thanks!

[notmandatory]

I'm not a big fan of the SignerError::Generic since I just removed bdk::Error::Generic in #1028. But in this case I don't see an simple way around it. If it becomes annoying we can fix it in 2.0 release.

[notmandatory]

ACK f1124d4

[notmandatory]

Can merge this one after the new CI issues are fixed with #1247 (after it's ACKd and merged).

[evanlinjin]

ACK f1124d4

I don't like SignerError::Generic, however I don't see a better option without taking too much time. We will change the API greatly for 2.0 anyway (as @danielabrozzoni mentioned: #1161 (comment)).

[danielabrozzoni]

Do you think it would be better to rename SignerError::Generic to SignerError::ExternalTraitImplementationError or something better? This would make it clear that it's needed only for external libraries implementing the Signer trait.

[notmandatory]

How about SignerError::External with doc that explains this is for external trait implementation errors? Or I'd be fine with the longer version too.

[danielabrozzoni]

Thanks, I rebased and changed Error::Generic to Error::External. LMK if the docs look ok or if they can be improved!

[notmandatory]

reACK 105d70e