--- Log opened Sun Oct 15 00:00:57 2023
01:24 -!- salvatoshi [~salvatosh@45.126.184.248] has quit [Ping timeout: 255 seconds]
03:25 -!- jon_atack [~jonatack@user/jonatack] has quit [Read error: Connection reset by peer]
03:26 -!- jonatack [~jonatack@user/jonatack] has joined ##miniscript
05:43 <@sipa> i realized that the "maybe" satisfaction algorithm we have doesn't actually work
05:44 <@sipa> it's unused in bitcoin core currently, but it'd be nice to use it for witness size estimation somehow sometime, and for testing
05:45 <@sipa> the issue is this: what if you have a branch between A (with sig, smaller) and B (without sig, bigger)
05:45 <@sipa> if both are definitely available, you pick B (non-sig is preferred)
05:47 <@sipa> if both are maybe available, our current algorithm also picks B and marks it as maybe, without sig - but it's also possible that at actual signing time, A is available and B isn't
05:47 <@sipa> and in that case, the result would have a sig
05:48 <@sipa> so "maybeness" isn't a property of just the overall satisfaction, but of the individual properties in it
05:49 <@sipa> my suggested solution: remove the "maybe" availability (except in the API), and internally just reason about the best per-type satisfaction/dissatisfactions
05:50 <@sipa> specifically, i think there are 5 possible types of satisfactions/dissatisfactions: (a) without-sig non-malleable (b) with-sig non-malleable (c) without-sig malleable (d) with-sig malleable (e) unavailable
05:51 <@sipa> so we'd always compute all 5, for each subexpression, for satisfaction and dissatisfaction
05:51 <@sipa> each would be an optional to reflect whether that type is possible at all
05:52 <@sipa> "Availability::NO" would correspond to only (e) being possible
05:52 <@sipa> "Availability::YES" would correspond to only (a), (b), (c), or (d) being possible
05:52 <@sipa> but Availability::MAYBE would correspond to having both (e) and one or more of (a)-(d) being possible
06:03 <@sipa> and when computing a concatenation or disjunction between these aggregates of up to 5 satisfactions, you go over all (up to 25) combinations, and within each apply the current rules (compute new type, take the minimum satisfaction within each branch for disjunctions)
06:04 <@sipa> but when there are multiple combinations that yield the same type, take the _maximum_ among those, because this corresponds to different possibilities about what's available, not different possibilities that will exist at satisfaction time
06:16 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 252 seconds]
06:16 -!- jonatack [~jonatack@user/jonatack] has joined ##miniscript
06:33 -!- jonatack [~jonatack@user/jonatack] has quit [Read error: Connection reset by peer]
06:34 -!- jon_atack [~jonatack@user/jonatack] has joined ##miniscript
06:53 -!- jonatack [~jonatack@user/jonatack] has joined ##miniscript
06:53 -!- jon_atack [~jonatack@user/jonatack] has quit [Read error: Connection reset by peer]
08:44 -!- jonatack [~jonatack@user/jonatack] has quit [Read error: Connection reset by peer]
08:44 -!- jon_atack [~jonatack@user/jonatack] has joined ##miniscript
18:30 -!- jon_atack [~jonatack@user/jonatack] has quit [Ping timeout: 255 seconds]
18:30 -!- jonatack [~jonatack@user/jonatack] has joined ##miniscript
19:46 -!- jonatack [~jonatack@user/jonatack] has quit [K-Lined]
19:57 -!- jonatack [~jonatack@user/jonatack] has joined ##miniscript
22:50 -!- salvatoshi [~salvatosh@103.151.37.100] has joined ##miniscript
--- Log closed Mon Oct 16 00:00:57 2023