--- Log opened Thu Dec 02 00:00:49 2021 08:53 < darosior> So i'm back at implementing the signing support since yesterday and i'm pondering whether it makes sense for the internal wallet to be able to set nSequence and nLockTime if spending from a Miniscript descriptor with such challenges. I have the signing support and they are solvable but it makes sense for it to only be usable with PSBTs (as it will 08:53 < darosior> be the case for hash preimage challenges anyways) rather than also supported "internally". On the other hand it seems awkward to have descriptors that are importable, solvable (and "signable") but to not be able to spend from them using eg `sendtoaddress`. 08:53 < darosior> I'm looking for others' opinions 08:54 < darosior> achow101 maybe? 09:55 -!- gene [~gene@gateway/tor-sasl/gene] has joined ##miniscript 09:56 < darosior> Hmm so actually for preimage challenges we'd need to implement PSBT_IN_RIPEMD160, PSBT_IN_SHA256, etc.. In the PSBT code.. 10:22 < achow101> darosior: why would sendtoaddress not work? 12:41 < darosior> achow101: because we would not set the nSequence and nLockTime field of the spending transaction accordingly 12:43 <@sipa> right, the issue is that in order to sign with a particular set of keys/hashes in certain miniscript, you also get conditions on locktime/nsequence 12:43 <@sipa> and it's of course possible for the miniscript signing code to only trigger for transaction signing attempts where those locktime/nsequence conditions are satisfied, that's not the problem 12:44 <@sipa> but perhaps we want to use the miniscript information too for constructing the transaction in the first place, before signing is a question 12:44 <@sipa> darosior: is that what this is about? 12:44 < darosior> sipa: yes 12:48 < darosior> To be honest i just didn't implement it, as it really seemed messy. Now i wonder how best to error if the user imported a (private) Miniscript descriptor and tries to sendtoaddress from this wallet (we could set nLockTime and nSequence in some convoluted ways but for preimages this would definitely require new information from the user and it seems 12:48 < darosior> out of the scope of `sendtoaddress` and co.). Just an error at signing time seems ok to me (current state of things) but maybe i'm being lazy 12:50 <@sipa> this all factors into the (unsolved) question how to make transaction construction be aware of e.g. which signers are present 12:57 < achow101> in general, it seems like the idea of the wallet figuring out what to sign for rapidly falls apart in the face of complex scripts 13:15 < darosior> So the application, client of the wallet, should be providing all the information it has to the wallet for it to then figure out the most optimal available branch of the Script to sign for, if there is one at all. That's the PSBT flow? 13:15 < darosior> I think what i'll go for is just that the simple flow (sendtoaddress &co) can only spend from miniscripts with pubkey (which may be hashed) challenges. Open to ideas on how best to translate to the user a failure to solve a more complex Script without being presented a PSBT but i guess the population of users both importing a miniscript descriptor 13:15 < darosior> with timelocks/hashlocks and then bug on why `sendtoaddress` can't automagically sign would be pretty small 16:18 -!- gene [~gene@gateway/tor-sasl/gene] has quit [Remote host closed the connection] 16:18 -!- gene [~gene@gateway/tor-sasl/gene] has joined ##miniscript 16:27 -!- gene [~gene@gateway/tor-sasl/gene] has quit [Quit: gene] 16:46 -!- roconnor [~roconnor@coq/roconnor] has quit [Ping timeout: 256 seconds] 17:07 -!- roconnor [~roconnor@coq/roconnor] has joined ##miniscript 18:34 -!- kallewoof [~quassel@user/kallewoof] has quit [Ping timeout: 268 seconds] --- Log closed Fri Dec 03 00:00:50 2021