--- Log opened Thu Dec 23 00:00:09 2021
03:50 -!- enick_581 [~afilini-m@51.15.93.184] has joined ##miniscript
05:17 < darosior> Why in the satisfier, when choosing between two sats, do we pick the biggest satisfaction (in terms of witness size) of the two if their availability is MAYBE?
05:18 < darosior> We take the smallest if the availability is YES, which makes sense to me. But i'm not able to guess why we'd ever want a larger satisfaction? Especially only based on the fact that we don't know whether it'll be there at signing time
05:19 <@sipa> I think that codepath (and MAYBE availability in general) is only for computing witness sizes.
05:19 <@sipa> And there you want an upper bound if you're not sure.
05:25 < darosior> But it's called in Choose (https://github.com/sipa/miniscript/blob/2e0734da14e85fb53cd5a96b98cfb7004e289202/bitcoin/script/miniscript.cpp#L326-L354), which is called by ProduceInput (Satisfy) (https://github.com/sipa/miniscript/blob/2e0734da14e85fb53cd5a96b98cfb7004e289202/bitcoin/script/miniscript.h#L660)
05:26 < darosior> So it makes sense for worst case sat size estimation but then not so much for the satisfaction itself?
05:27 <@sipa> for actual satisfaction you can't have MAYBEs
05:27 <@sipa> i mean... you have a key or you don't
05:27 < darosior> Oh right..
08:09 < darosior> So re the issue with a satisfaction that overflows MAX_OPS, we may want Choose() to also choose the sat with less ops
08:10 < darosior> Or since you don't pay per OP, actually optimize for size and then if you get above MAX_OPS retry by optimizing for the number of ops
08:12 <@sipa> Yeah, but how much?
08:13 <@sipa> Because only optimizing for ops may result in an excessive weight too.
08:13 <@sipa> You can do things like start by using a metric = 0.99 weight + 0.01 ops, and optimizing for that.
08:14 <@sipa> And if it still doesn't work, retry with 0.98 weight + 0.02 ops etc.
08:19 < darosior> Yeah and if you hit the maximum number of max elements you give up. But we only optimize for size, not so much for the budget of witness stack elements
08:55 < darosior> But i don't think it's very useful to try to optimize for non-sane scripts.
08:56 <@sipa> Right.
08:59 <@sipa> darosior: so does the `Span{Result}` actually help, or do you just always get the problem with old clang?
09:00 <@sipa> Span<Result> I mean.
09:00 < darosior> It does with clang <12
09:00 < darosior> (tried clang-9, clang-11 and clang-12)
09:01 <@sipa> So old clang only works with `Span<Result>{...}`, new clang works with both that and `Span{...}`?
09:03 <@sipa> Can you ACK the latest commit, btw?
09:03 < darosior> I did not try Span<Result> with clang++-12, doing now
09:03 < darosior> But i didn't think it could cause any issue
09:03 <@sipa> It shouldn't.
09:04 < darosior> But otherwise yes
09:04 <@sipa> Just wanted to make sure adding the `<Result>` did anything at all (for old clang).
09:06 < darosior> Ok, yes it does succeed to compile whereas it doesn't without.
09:06 <@sipa> https://clang.llvm.org/cxx_status.html claims support for template argument deduction is supported as of clang 7.
09:08 < darosior> I can try with clang-11 10 and 9 from clang's release if that helps. I used 9 and 11 from Debian testing.
09:08 <@sipa> No need. I'm pretty sure the issue is a bug in the user-specified template deduction rules in old clang. Specifying the template explicitly results in very conventional C++11 stuff only.
09:14 < darosior> Done for the commit, i messed up the branches
09:31 < darosior> I tried anyways with clang's released clang++-11. So it's not specific to the Debian one, fwiw
10:27 <@sipa> One more: https://github.com/sipa/miniscript/pull/85
16:25 -!- enick_581 [~afilini-m@51.15.93.184] has quit [Ping timeout: 256 seconds]
16:53 -!- enick_581 [~afilini-m@2001:bc8:1828:245::2] has joined ##miniscript
16:58 -!- enick_581 [~afilini-m@2001:bc8:1828:245::2] has quit [Ping timeout: 268 seconds]
16:59 -!- enick_581 [~afilini-m@51.15.93.184] has joined ##miniscript
17:15 -!- enick_581 [~afilini-m@51.15.93.184] has quit [Ping timeout: 260 seconds]
17:16 -!- enick_581 [~afilini-m@2001:bc8:1828:245::2] has joined ##miniscript
17:23 -!- enick_581 [~afilini-m@2001:bc8:1828:245::2] has quit [Ping timeout: 268 seconds]
22:45 < darosior> Oh nice!
22:46 < darosior> I had planned to look into this one :) I think it's the last recursive one
23:26 < darosior> Read it, but not sure i'll be able to review it today. Btw if you can give another look to the updated fuzzing PR. Not sure we want it in the repo, so i don't mind if you prefer not to. But your look is always helpful
--- Log closed Fri Dec 24 00:00:10 2021