`Satisfier::lookup_tap_key_spend_sig(&self)` should take the pubkey as an argument

[benma]

rust-miniscript/src/miniscript/satisfy.rs

Line 38 in f023c39

fn lookup_tap_key_spend_sig(&self) -> Option<bitcoin::taproot::Signature> { None }

Compare to AssetProvider in plan.rs:

rust-miniscript/src/plan.rs

Line 50 in f023c39

fn provider_lookup_tap_key_spend_sig(&self, _: &Pk) -> Option<usize> { None }

Seeing that AssetProvider mirrors Satisfier, they should be consistent, and it seems helpful to include the pubkey in the satisfier function so one can look up the signature based on it.

[apoelstra]

Yeah. I could go either way on this (what should the function do if you pass the wrong pubkey? The natural thing to do is to check whether you have a secret key for the passed pubkey, and then sign the keyspend sighash if so, but this may be dangerous) but agreed they should be consistent.

And I have a weak preference for adding the public key as an argument. When I was using the satisfy API recently I really didn't like not having the pubkey directly available in my lookup function.

[benma]

what should the function do if you pass the wrong pubkey?

What do you mean? The lib's satisfier functions would call this function with the correct internal key.

(I also prefer passing the pubkey for convenience)

[apoelstra]

The lib's satisfier functions would call this function with the correct internal key.

Yeah, I guess that's the workflow that users would use in 99.9% of cases.

But in theory, people can call these methods with whatever keys they want, and implementors of the method would have to make a decision about how to handle that.

[benma]

Does the same problem appear for lookup_tap_leaf_script_sig(), which also receives the pubkey?

[apoelstra]

Well, the tapleaves are Miniscripts so they may have multiple keys ... but yeah, I guess it's conceptually the same thing. Implementors should still give half a thought to what happens when they're asked to sign with an "unexpected" key.

[apoelstra]

FWIW I think it might be totally safe. I've been thinking about this for a few hours and struggling to imagine the harm in signing either a keyspend or a scriptspend with a key that doesn't apply.