--- Log opened Wed Oct 18 00:01:02 2023
00:33 <@darosior> Nice!
04:11 -!- salvatoshi [~salvatosh@103.151.37.100] has quit [Ping timeout: 240 seconds]
04:53 -!- salvatoshi [~salvatosh@103.100.173.166] has joined ##miniscript
07:23 -!- salvatoshi [~salvatosh@103.100.173.166] has quit [Ping timeout: 255 seconds]
07:30 -!- salvatoshi [~salvatosh@103.100.173.166] has joined ##miniscript
07:34 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 240 seconds]
07:36 -!- jonatack [~jonatack@user/jonatack] has joined ##miniscript
08:56 -!- salvatoshi [~salvatosh@103.100.173.166] has quit [Ping timeout: 255 seconds]
09:37 <@sipa> i found some fuzzing failures overnight, which i think i understand
09:38 <@sipa> or_b is really unique in that its satisfaction rule (x.sat + z.nsat) | (x.nsat + z.sat) | (x.sat + z.sat) uses the two .sat values twice
09:39 <@sipa> and this leads to a problem in reasoning, because if say x.sat has 2 possibilities, then the entire expression with two | operations will explore 4 possibilities, while there are only two
09:40 <@sipa> as in: it'll consider possibilities where the first x.sat takes one possibility, and the second takes another
09:41 <@darosior> I see
09:42 <@sipa> i know how to fix this, but i'll need a slightly different approach
11:16 -!- Netsplit *.net <-> *.split quits: ghost43_
17:00 -!- salvatoshi [~salvatosh@103.100.173.166] has joined ##miniscript
18:53 -!- salvatoshi [~salvatosh@103.100.173.166] has quit [Ping timeout: 240 seconds]
23:51 -!- salvatoshi [~salvatosh@103.151.37.100] has joined ##miniscript
--- Log closed Thu Oct 19 00:00:01 2023