--- Log opened Mon Jan 09 00:00:10 2023
02:00 -!- michaelfolkson [~michaelfo@138.68.143.20] has quit [Quit: ZNC 1.8.2 - https://znc.in]
02:02 -!- michaelfolkson [~michaelfo@138.68.143.20] has joined ##miniscript
02:37 -!- salvatoshi [~salvatosh@genymobile-2-6-86.fib.nerim.net] has joined ##miniscript
06:36 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 260 seconds]
06:39 -!- jonatack [~jonatack@user/jonatack] has joined ##miniscript
07:18 < darosior> andytoshi, sanket1729: Benma found an inconsistency between the C++ and Rust implementations on the calculation of 'e' on 'or_d' https://github.com/rust-bitcoin/rust-miniscript/pull/515
07:20 <@sipa> @darosior There is no difference; the first argument is required to have 'd' already.
07:20 <@sipa> It's an optimization in the c++ code, but both expressions are equivalent.
07:21 < darosior> sipa: but 'd' doesn't imply a *unique* unconditional dissatisfaction exists?
07:22 <@sipa> I haven't reasoned about the script semantics at all.
07:24 < darosior> For instance the Rust implementation says "or_d(c:pk_k(A),or_d(sha256(926a54995ca48600920a19bf7bc502ca5f2f7d07e6f804c4f00ebf0325084dbc),multi(2,B,C,D)))" is 'e'. The C++ one doesn't, and this makes sense: sha256() has numerous unconditional dissatisfactions, there so does
07:24 < darosior> "or_d(sha256(926a54995ca48600920a19bf7bc502ca5f2f7d07e6f804c4f00ebf0325084dbc),multi(2,B,C,D))".
07:24 <@sipa> I'm just saying that "d_x" and "d_x & d_y" always compute the same thing.
07:24 <@sipa> because d_x is required to be true
07:24 <@sipa> @darosior But are those non-malleable expressions?
07:25 <@sipa> If the left argument in or_d is not "d", then the expression is malleable, and reasoning about d is irrelevant.
07:26 < darosior> I must be missing something. This is about 'e', not 'd'.
07:26 <@sipa> Oh, wait.
07:28 <@sipa> Well, it's still true: "d_x" and "d_x & d_y" should always be identical for valid or_d's, because d_x is a requirement for or_d to be valid?
07:29 <@sipa> Nevermind, I'm still misreading.
07:30 <@sipa> Ok, I see.
07:32 <@sipa> darosior: So for an or_d to be non-malleable, e_x is required. So for the purpose of computing the "e" property, "e_z" and "e_x & e_z" are identical (because the only use of the "e" property is assessing malleability; if the subexpression is already malleable, e/f/s don't matter anymore).
07:34 < darosior> sipa: alright, it is because e_x is already in the "Requires" column that it isn't repeated in the "Properties" column's requirements. Makes sense. Thanks.
07:36 < darosior> And the Rust implementation must be detecting it as non-malleable, it still just assigns it the 'e' property anyways.
09:35 -!- salvatoshi [~salvatosh@genymobile-2-6-86.fib.nerim.net] has quit [Ping timeout: 265 seconds]
10:17 -!- salvatoshi [~salvatosh@lfbn-idf3-1-37-94.w81-249.abo.wanadoo.fr] has joined ##miniscript
11:40 -!- salvatoshi [~salvatosh@lfbn-idf3-1-37-94.w81-249.abo.wanadoo.fr] has quit [Ping timeout: 272 seconds]
13:23 -!- jonatack [~jonatack@user/jonatack] has quit [Quit: WeeChat 3.7.1]
13:26 -!- jonatack [~jonatack@user/jonatack] has joined ##miniscript
15:05 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 256 seconds]
15:08 -!- jonatack [~jonatack@user/jonatack] has joined ##miniscript
23:46 -!- salvatoshi [~salvatosh@genymobile-2-6-86.fib.nerim.net] has joined ##miniscript
--- Log closed Tue Jan 10 00:00:10 2023