--- Log opened Tue Oct 17 00:01:00 2023
00:43 -!- Earnestly [~earnest@user/earnestly] has joined ##miniscript
01:36 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 258 seconds]
04:10 <@darosior> I'm really not clear on how you would go about implementing your solution from above. You state "when there are multiple combinations that yield the same type, take the _maximum_ among those". But you don't want to do that at signing time (and i don't see why it would only yield a single type at signing time)? And how is taking the maximum among
04:10 <@darosior> those not the same as taking the largest satisfaction between two MAYBEs?
04:33 <@sipa> at signing time you only have YES and NO, which each translate to just one possibility; with one possibility there just never are multiple things to take tbe maximum between
04:35 <@sipa> it'd the MAYBEs that get translated to both an available and an unavailable option
04:35 -!- salvatoshi [~salvatosh@103.151.37.100] has quit [Ping timeout: 272 seconds]
04:35 <@sipa> i'm half done implementing; maybe it's easier to explain with code
04:38 <@sipa> darosior: maybe this helps: in what i'm proposing, the choice made between left and right inputs to an operator| is *always* the shortest of the two (but preferring without signature, and non-malleable)
04:39 <@sipa> it is between multiple *possibilities* that the maximum is taken
04:40 <@sipa> also always, but at signing time there will only ever be one possibility
04:40 <@darosior> Indeed i think it'll be clearer with code :)
05:28 -!- salvatoshi [~salvatosh@103.100.173.166] has joined ##miniscript
05:34 -!- salvatoshi_ [~salvatosh@103.100.173.166] has joined ##miniscript
05:37 -!- salvatoshi [~salvatosh@103.100.173.166] has quit [Ping timeout: 272 seconds]
06:52 -!- jonatack [~jonatack@user/jonatack] has joined ##miniscript
07:46 <@darosior> Isn't it the case that this issue arises when we shortcut to return one of A or B because the other one needs a sig, or is malleable? Can't this be simply fixed by never returning it if it's MAYBE in this case, ie: https://paste.ec/paste/wy6RrIs7#V-gNM1zcVUlfKMd5BHd5VUNhcWXyOb1yUkdFEvG0QXV
07:48 <@darosior> s/arises/only arises/
07:52 <@sipa> darosior: i'm not convinced that's correct, it's pretty hard to reason about i find
07:54 <@darosior> Where i'm coming from is: this issue only arises when we have to pick between either two maybes, or a maybe and a yes
07:54 <@sipa> because if you have a choice between a YES and a MAYBE, the result can be something that's maybe HASSIG and maybe not, possibly with different sizes
07:54 <@darosior> And then we return the MAYBE but it ends up being a NO at signing time
07:55 <@sipa> and it's not necessarily clear which of those two is "worst", because typically no-sig is better (you have to pick it if available), but if you end up with a choice between two no-sigs later, it becomes malleable, which then becomes non-preferred later
07:59 <@darosior> And your solution solves this without having to "go back"?
08:00 <@sipa> yes, by keeping track of all possibilities (but only keep the worst possibility, *within* types of stack)
08:00 <@darosior> Aaah
08:00 <@sipa> But when making a choice (in the sense of operator|) between two stacks, within the same type of stack, you prefer the smaller one.
08:01 <@darosior> And you only have to keep so many stacks, hence the 5 types from above
08:01 <@darosior> Took me some time but i'm getting where you landed :)
08:02 <@sipa> So I'm effectively keeping track of 10 different stacks per node: (nonmal-nosig, nonmal-sig, mal-nosig, mal-sig, and a meta "unavailable" stack to indicate the possibility that one may not exist at signing time), and all 5 for both satisfaction and dissatisfaction
08:05 <@sipa> and when performing an operator| between two stacks, you try all 25 combinations, use the existing (YES/NO, no MAYBE) rules to compute what you'd get for each (prefering the smallest when both types are the same), and if multiple of them result in the same type, take the largest *among those* possibilities
08:05 <@sipa> and similar with operator+
08:06 <@sipa> but the interface remains exactly the same: you have an InputStack type with constructors and operator+ and operator|, and internally it does all these 25 things when needed, keeping track of up to 5 resulting stacks rather than 1
08:06 <@sipa> i'm cleaning things up a bit and will push
08:06 <@sipa> though i still want to write exhaustive analysis to show it's correct too
08:10 <@darosior> That makes sense to me now
08:10 <@darosior> No rush
08:23 <@sipa> All unit and fuzz tests pass. This cannot be.
08:23 <@sipa> (of course, we don't have any tests that exercise MAYBE, but I'd have expected that I'd introduce some kind of bug when rewriting this just for YES/NO)
08:26 <@sipa> https://github.com/bitcoin/bitcoin/blob/master/src/coins.h#L89L103
08:26 <@sipa> eh
08:26 <@sipa> https://github.com/sipa/bitcoin/commits/202310_miniscript_maybe
08:27 <@sipa> only the last commit changes behavior
08:30 <@darosior> Have you tested it with your fuzzer which caught the bug in the first place yet?
08:30 <@sipa> No, not yet.
08:36 -!- salvatoshi_ [~salvatosh@103.100.173.166] has quit [Ping timeout: 255 seconds]
08:44 -!- jonatack [~jonatack@user/jonatack] has quit [Quit: WeeChat 4.0.5]
10:49 <@sipa> darosior: i'm confused
10:50 <@sipa> it appears to me that for j:X to be non-malleable, X needs to be "f"
10:50 <@sipa> ah, no, just e
10:54 <@sipa> the type system looks right, but i'm still getting a failure
11:20 <@sipa> found it!
11:21 <@sipa> the way the dissatisfaction for or_b is written results in (temporary) violations of the sanity checker
11:22 <@sipa> but it can be rewritten in an equivalent way to avoid that
11:58 -!- jonatack [~jonatack@user/jonatack] has joined ##miniscript
12:09 <@sipa> darosior: starting to look promising, https://github.com/sipa/bitcoin/commits/202310_miniscript_maybe
12:13 <@sipa> still no exhaustive testing to see if upper bounds are actually reachable
16:52 -!- salvatoshi [~salvatosh@103.151.36.226] has joined ##miniscript
18:37 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Ping timeout: 252 seconds]
18:37 -!- ghost43_ [~ghost43@gateway/tor-sasl/ghost43] has joined ##miniscript
18:48 -!- salvatoshi [~salvatosh@103.151.36.226] has quit [Ping timeout: 255 seconds]
21:16 -!- jonatack [~jonatack@user/jonatack] has quit [Read error: Connection reset by peer]
21:16 -!- jonatack [~jonatack@user/jonatack] has joined ##miniscript
23:04 -!- salvatoshi [~salvatosh@103.151.37.100] has joined ##miniscript
23:52 -!- salvatoshi_ [~salvatosh@103.151.37.100] has joined ##miniscript
23:53 -!- salvatoshi [~salvatosh@103.151.37.100] has quit [Quit: Leaving]
23:53 -!- salvatoshi_ [~salvatosh@103.151.37.100] has quit [Client Quit]
23:53 -!- salvatoshi [~salvatosh@103.151.37.100] has joined ##miniscript
--- Log closed Wed Oct 18 00:01:02 2023