Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sign_psbt should be told what policy to sign for. #15

Open
darosior opened this issue Feb 1, 2023 · 1 comment
Open

sign_psbt should be told what policy to sign for. #15

darosior opened this issue Feb 1, 2023 · 1 comment

Comments

@darosior
Copy link
Member

darosior commented Feb 1, 2023

This was reported to me by @bigspider, and i think it makes sense. Copy paste of the report follows.

async fn sign_tx(&self, tx: &mut Psbt) -> Result<(), Error>;

I think you shouldn't abstract the policy in the HWI trait; sign_psbt without specifying what policy you're signing with puts the burden of figuring it out to the library.
But the caller of sign_psbt always knows which policy you're signing with.
if you have multiple inputs with different policies, most likely it's going to be from different signers − so multiple calls to sign_psbt with different policies
sure, one might imagine signing with multiple policies at the same time (if they are all controlled by the same hardware wallet), but I wouldn't bother yet, can generalize in the future

@edouardparis
Copy link
Member

It does indirectly.
Before signing with ledger, the policy must be loaded in the client struct:
https://github.com/wizardsardine/async-hwi/blob/master/src/ledger.rs#L39

I defined the interface in a way that it is the simplest and the most common with specter which does not need the policy in the sign_psbt request (Already loaded in specter device memory).

But maybe we should explore other way to do it like for example:

harware_wallet.with_policy(&policy).sign_psbt(&mut psbt)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants