Question: How to build unlocking script

[miketery]

Given a mini script, how can I use this library to build a an unlocking script to satisfy it (presume I know which private keys I have).

[tcharding]

Hi @miketery, I'm not sure I fully understand the question but I'll try to provide some starting points for you to dig more. Perhaps someone else more knowledgeable will jump in and correct me or add more. By unlocking script do you mean how does one sign a transaction? You could take a look at the SighashCache API in rust-bitcoin to see how to get a message that you can then sign. For an example of signing you could check out ecdsa-psbt example, or you could take a look at this PR.

There are more PSBT things you can do with this lib, for example, the Finalizer role.

[LLFourn]

I think the question is more "given a set of keys and a descriptor (and perhaps a set of hash preimages), how do I know which subset of keys I need to sign with and with what signature scheme and what digest". I think the answer is that this library doesn't have that feature but it should. It can only tell you where to put signatures after you've generated them with the satisfaction module. I happen to be working on building that functionality. Hopefully I can demonstrate the approach soon. Would love to know if I'm mistaken and there is some way of composing things together to get this.

[miketery]

Hey @tcharding , thanks for responding. I'm familiar with how to generally sign (i.e. satify checksig). The thing I'm trying to get at is how do I consturct the unlock script when there are multiple paths.

For example

// a given miniscript
or(pk(key_1),and(thresh(2,pk(key_2),pk(key_3),pk(key_4)),older(12960)))

// generates bitcoin script
<key_1> OP_CHECKSIG OP_IFDUP OP_NOTIF
  2 <key_2> <key_3> <key_4> 3 OP_CHECKMULTISIGVERIFY <a032>
  OP_CHECKSEQUENCEVERIFY
OP_ENDIF

It's basically a deadman switch / estate plan. me || (2 of 3 multisig && timelock)

Pretty straight forward how to execute the me unlock. However to execute the second branch, I have to provide a dummy signature, followed by two signatures to satisfy the multisig. It seems clear from the example, but could the library construct this.

In essence, if I give it my public key and associated signature, it'll produce unlocking script of just my signature (that will satisfy the unlock).

However if I provide two tuples; (pk(key_2), sig), (pk(key_3), sig), and we know that the timelock is valid, then it will spit out an unlocking script that includes the 2 sigs from key_2 and key_3, plus the dummy sig (needed to enter the multisig branch for execution).

[miketery]

signature scheme and what digest

What do you mean by digest? Is this like classic (ecdsa?) vs. schnorr? What's good term for the classic one.

satisfaction module

This might be what I'm looking for! I'll try to search and read about this.

[LLFourn]

signature scheme and what digest

What do you mean by digest? Is this like classic (ecdsa?) vs. schnorr? What's good term for the classic one.

by digest I meant "SigHash" -- the "message" you pass to the signing algorithm. I think we call it Legacy vs segwit.

This might be what I'm looking for! I'll try to search and read about this.

Maybe. If it's possible to just signing with all keys up front and then put the signatures in a PSBT or something you can get miniscript to create an optimal witness provided all those signatures. I think it would be good to have a more powerful module that can create something like a "satisfaction plan" just giving the xpubs your purport to own. This can tell you the details of a particular satisfaction path and help you generate the signatures things you need to execute it.

[apoelstra]

Given a mini script, how can I use this library to build a an unlocking script to satisfy it (presume I know which private keys I have).

This question is a bit incomplete -- a miniscript by itself does not have enough information to produce an unlocking script. I presume you mean that you have a descriptor. I also assume you have a transaction which spends an output controlled by this descriptor -- otherwise you have nothing to sign and certainly can't produce a witness. In this case there are two ways to do it:

1. As @LLFourn hints at, you can put everything into a PSBT: create a PSBT with PartiallySignedTransaction::from_unsigned_tx then attach the descriptor information with PsbtExt::update_desc. You can update the PSBT with whatever else you want (preferred sighash modes, locktimes, etc). Then obtain a digest to sign with using PsbtExt::sighash_msg (this really ought to be in rust-bitcoin..) Attach all your signatures to the PSBT, which I think you have to do manually by inserting them in the appropriate PSBT field. Finally, use this library to finalize everything with PsbtExt::finalize and extract the transaction with PartiallySignedTransaction::extract_tx.
2. Alternately you can do things "manually": starting from your descriptor, call Descriptor::get_satisfaction providing an object which implements the Satisfier trait. This is an easy trait to implement: create an object which can access all your private keys, then implement whatever lookup_*_sig methods you think you'll need for your script (for pre-Taproot scripts this is probably just lookup_ecdsa_sig). This will return a scriptsig and witness stack that you can just attach to the appropriate input of your transaction. Obtaining the sighash to sign is an exercise for the reader.

Note that some of the docs.rs links I provided are for this library and some are for rust-bitcoin.

I think it would be good to have a more powerful module that can create something like a "satisfaction plan" just giving the xpubs your purport to own. This can tell you the details of a particular satisfaction path and help you generate the signatures things you need to execute it.

What do you mean by this, exactly? Prior to Taproot every path is "the same" in that you're signing all the same data. After Taproot you also need to know the control block but Satisfier::lookup_tap_leaf_script_sig already provides that.

If you are simply curious about "can I satisfy this script given this set of keys" you can implement Satisfier so it returns dummy signatures and see if it works. I would like to directly support this in semantic::Policy but I guess we never got around to that. (There is a related question, "what is the max witness size given that certain keys are definitely present, definitely not present, or unknown", which surprisingly might be NP-complete even though the related question for any pair of those conditions is easy... but simply determining "satisfiable or not?" is always easy.)

[LLFourn]

What do you mean by this, exactly? Prior to Taproot every path is "the same" in that you're signing all the same data. After Taproot you also need to know the control block but Satisfier::lookup_tap_leaf_script_sig already provides that.

If you are simply curious about "can I satisfy this script given this set of keys" you can implement Satisfier so it returns dummy signatures and see if it works. I would like to directly support this in semantic::Policy but I guess we never got around to that.

Right. But what if you want to know which of the keys in the set were actually used? If xprivs for one of your xpubs is held on a hardware wallet you don't want to have to engage it unnecessarily. I thought of:

1. Try each possible subset of keys which has worst case combinatorial complexity
2. Try and shove the public key in as one of the components of the signature so you can look at the dummy witness to see which keys were used.
3. As an enhanced version of (2) keep a mapping in the custom Satisifer from dummy sigs to which keys gave them out.

I felt (1) and (2) were too hacky but honestly I only thought of (3) just now which seems like a decent way of going. I think I'll try that before continuing with my previous approach. Thanks for hinting me in the right direction here. If I succeed here I'll try and contribute this "public key recording" satisfier if it makes sense.

[miketery]

@apoelstra thank you for the response. I don't understand all that you shared, but it gave me enough to parse an example, and I believe get to what I wanted.

The descriptor here is of a 2 of 3 multisig:
https://github.com/rust-bitcoin/rust-miniscript/blob/master/examples/sign_multisig.rs#L29-L30

And then here are tuples of (pk, sig) passed to the satisfy function.
https://github.com/rust-bitcoin/rust-miniscript/blob/master/examples/sign_multisig.rs#L66-L81

Which then once 2 (or 3 but irrelevant) are passed then its able to produce the witness:
https://github.com/rust-bitcoin/rust-miniscript/blob/master/examples/sign_multisig.rs#L81

OP_0 <Sig_1> <Sig_2> <witness script>

That final thing is what I was looking for based on the descriptor, and tuples of pubkeys & sig. Maybe I'm also misusing the term unlocking script and I should be calling it witness? or witness stack?

One final question, I get that in this simple example it works (i.e. multisig), but I presume it will also work in a more complex example if there is a need to execute the non default conditional branch?

@LLFourn

Try and shove the public key in as one of the components of the signature so you can look at the dummy witness to see which keys were used.

I like the idea of a dummy witness! Maybe it can even generate multiple since there are likely permutations that can satisfy the script.

Feel free to close, I feel my questions are answered. But also don't want to close if ya'll still have more to say / discuss.

Cheers!

[apoelstra]

Right. But what if you want to know which of the keys in the set were actually used? If xprivs for one of your xpubs is held on a hardware wallet you don't want to have to engage it unnecessarily. I thought of:

I'm actually not sure that you can do it even by putting state in the Satisfier ... the satisfier trait is designed to just do lookups, and there's no guarantee that every sig it tries to look up will actually be used. (If this were true you wouldn't even need the feature!) In any case I agree that this is a useful thing to support and it should be a first-class feature. Can you open a separate issue?

One final question, I get that in this simple example it works (i.e. multisig), but I presume it will also work in a more complex example if there is a need to execute the non default conditional branch?

Yep. It will take the optimal (smallest size) branches based on which ones it's possible to satisfy with the given set of pubkeys/sigs/hash preimages/whatever.

Feel free to close, I feel my questions are answered. But also don't want to close if ya'll still have more to say / discuss.

I vote to close. @LLFourn is discussing a separate feature request.