--- Log opened Fri Jan 13 00:00:14 2023
00:05 -!- salvatoshi [~salvatosh@genymobile-2-6-86.fib.nerim.net] has joined ##miniscript
03:01 -!- jonatack3 [~jonatack@user/jonatack] has joined ##miniscript
03:02 -!- jonatack2 [~jonatack@user/jonatack] has quit [Read error: Connection reset by peer]
03:28 -!- midnight [~midnight@user/midnight] has quit [Ping timeout: 272 seconds]
03:29 -!- midnight [~midnight@user/midnight] has joined ##miniscript
05:26 -!- w0xlt_ [sid555702@id-555702.ilkley.irccloud.com] has quit [Excess Flood]
05:26 -!- w0xlt_ [sid555702@id-555702.ilkley.irccloud.com] has joined ##miniscript
05:27 -!- w0xlt_ [sid555702@id-555702.ilkley.irccloud.com] has quit [Excess Flood]
05:27 -!- w0xlt_ [sid555702@id-555702.ilkley.irccloud.com] has joined ##miniscript
05:34 -!- w0xlt_ [sid555702@id-555702.ilkley.irccloud.com] has quit []
05:34 -!- w0xlt [sid555702@id-555702.ilkley.irccloud.com] has joined ##miniscript
08:30 -!- jonatack3 [~jonatack@user/jonatack] has quit [Read error: Connection reset by peer]
08:30 -!- jonatack3 [~jonatack@user/jonatack] has joined ##miniscript
08:53 -!- salvatoshi [~salvatosh@genymobile-2-6-86.fib.nerim.net] has quit [Ping timeout: 272 seconds]
09:56 < w0xlt> In rust-miniscript, is it possible to convert `bitcoin::blockdata::script pub struct Script` to `miniscript::Descriptor`?
11:23 -!- w0xlt [sid555702@id-555702.ilkley.irccloud.com] has quit [Excess Flood]
11:23 -!- w0xlt [sid555702@id-555702.ilkley.irccloud.com] has joined ##miniscript
11:24 -!- w0xlt [sid555702@id-555702.ilkley.irccloud.com] has quit [Client Quit]
11:24 -!- w0xlt [sid555702@id-555702.ilkley.irccloud.com] has joined ##miniscript
12:01 -!- jonatack [~jonatack@user/jonatack] has joined ##miniscript
12:01 -!- jonatack3 [~jonatack@user/jonatack] has quit [Ping timeout: 248 seconds]
14:39 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 248 seconds]
14:40 -!- jonatack [~jonatack@user/jonatack] has joined ##miniscript
16:53 -!- benma [~benma@2a02:168:5366:0:f7c2:b229:3cc7:8874] has joined ##miniscript
16:55 < benma> hi everyone. i am currently doing a deep dive into miniscript. darosior made me aware of this channel, thanks darosior :)
17:00 <@sipa> hi!
17:00 < benma> i was wondering about a particular thing: when counting the ops to check the ops limit, the multisig keys are treated specially, as they appear in the witness, not in the script. however, why not just always include the keys in the count unconditonally? the way i understand it is that the only case where the max ops count would be reduced is if no satisfaction exists that includes the keys, but why would anyone incl
17:00 < benma> ude a multisig in a script if it can never be executed?
17:01 <@sipa> you could have an or_b between two multi's for example
17:01 <@sipa> you can never execute both in the same spend, so the maximum of the two ops is what matters
17:02 < benma> yeah, i get that the maximum of both should be taken, but then why are they accounted for separately?
17:02 < benma> talking about this: https://github.com/sipa/miniscript/blob/be0655fe76a7842eafbca8cfbbde2210126eb413/bitcoin/script/miniscript.h#L313
17:03 < benma> sounds to me like `k` could just be include in `count` and skip all the sat/dsat paths
17:04 < benma> the only case that i can come up with where it matters in in scripts like `and_v(v:0, multi(...))`, where the multisig is never executed
17:06 <@sipa> Hmm, I don't think that's right. Every subexpression can be non-executed, executed and satisfied, or executed and dissatisfied.
17:06 <@sipa> And which of those happen depends on what the expressions around it do.
17:07 <@sipa> E.g. or_c doesn't execute the second branch if the first is satisfied, while or_b always executes both.
17:09 <@sipa> But maybe I don't understand exactly what you mean.
17:11 < benma> maybe i can rephrase. if in CalcOps() you returned `{1+keys.size(), 0, 0}` for multisig here:
17:11 < benma> https://github.com/sipa/miniscript/blob/be0655fe76a7842eafbca8cfbbde2210126eb413/bitcoin/script/miniscript.h#L781
17:12 < benma> then the resulting op limit is still safe to use in the limit check, as the keys are always counted
17:13 < benma> is there a miniscript that you can think of where this sigop limit is too conservative and the keys should not have been counted?
17:14 <@sipa> let me think about that
17:22 < benma> perhaps a more general question is: if there is a subexpression in a miniscript that can never be executed under any possible satisfaction, shouldn't the miniscript be marked as invalid? if it was, then the ops count algo could discard this added complexity.
17:23 < benma> and of course also help the user avoid using scripts that are overly complicated :)
17:30 <@sipa> Hmm, clearly it's possible, with an or_c(1,X), the X is never executed
17:30 <@sipa> But I don't understand what this has to do with your point.
17:32 <@sipa> Let me try to think this through more.
17:41 < benma> yeah it's obviously possible, i.e. `andor(0,multi(1,k1,k2),pk(k3))` is a valid miniscript where the multi can never be executed, so the keys are not counted towards the limit. this is clear enough. this script is clearly not desirable though, as it is equivalent to `pk(k3)`. more generally, it seems to be any miniscript with such non-executable subexpressions is not desirable. but maybe i am wrong?
17:47 <@sipa> Yeah, I don't see how they can be useful - they're always equivalent to a simpler one.
17:52 < benma> so patterns like `and(0, ...)` and `or(1, ...)` could all be rejected? 
17:54 < benma> `thresh(...)` too if there are no `k` of `n` that satisfy  
17:56 <@sipa> Yeah, they could; I'm not convinced that's useful, though.
17:56 <@sipa> You seem to think that disallowing never-executed subexpression would simplify the ops counting logic?
17:56 < benma> the reason i am thinking about all of this is because i am implementing a parser/analyzer for learning, and was surprised at the complexity of CalcOps(), thinking that no sane script would this. 
17:57 < benma> of course making an analysis for disallowing never-executed subexpressions just moves the complexity elsewhere, but at least there it seems a little more useful
17:58 < benma> *no sane script would need this
17:58 <@sipa> well we do have to consider two distinct use-cases i think
17:59 <@sipa> one is miniscript as an analysis tool, part of the workflow of designing scripts and reasoning about their correctness
17:59 <@sipa> and for that, useless constructions are pointless
18:00 <@sipa> but on the other hand, it can also function as a generic signing/spending tool, and if you already have funds locked up accidentally in a partially-useless script, you may still want to be able to get them out
18:01 < benma> you mean for backwards compatibility for miniscript users who used such scripts? 
18:01 <@sipa> well, or anything
18:02 <@sipa> i mean: all else being equal, miniscript covers as wide a set of scripts as possible, even apparently useless things
18:05 < benma> from this perspective it makes sense. thanks!
18:07 <@sipa> That said, I'm not sure we made the right call with some of resource limit computations, and being as accurate as they are.
18:07 <@sipa> It's definitely possible that simpler constructions are possible that don't practically disallow anything useful, but would have simplified implementations.
18:08 < benma> you mean different kinds of fragments, or are you talking strictly about the limit computations?
18:09 <@sipa> i was talking about limit computations, but it certainly applies to other things of the design too
18:10 < benma> but as you say, they should be accurate when used as a generic signing tool. what alternatives did you have in mind that might have been better in hindsight?
--- Log closed Sat Jan 14 00:00:15 2023