--- Log opened Sat Jul 24 00:00:16 2021
00:04 -!- dr-orlovsky [~dr-orlovs@31.14.40.19] has quit [Quit: ZNC 1.8.0 - https://znc.in]
02:30 < robertspigler> There was a conversation in this channel previously about committing to the depth of a leaf for Taproot - was that resolved?
06:41 < sanket1729_> andytoshi: Updating the code so that it only enforces the minimality for fuzzing roundtrip tests. When in non-fuzzing mode, we accept everything. 
08:32 < sanket1729_> consider the fragment. j:pk(A), this has unique dissatisfaction, but our type system cannot detect it.
08:33 < sanket1729_> The implementation which dgpv has correctly marks this as having the `e` property
08:34 < sanket1729_> But I think that requires extra tracking of checking whether the dissatisfaction of fragment starts with `0` on stack top.
08:35 < sanket1729_> Regardless, the expected behavior is that all other implementations should follow the spec.
08:43 <@sipa> hmm, is that an oversight?
08:53 < sanket1729_> Yeah, I think so. 
09:01 < sanket1729_> So, currently we marking or_d(j:pk(A),pk(B)) are malleable when it is not. But when we mark as non-malleable it is non-malleable. 
09:01 <@sipa> right, it's just overly conservative
09:19 < sanket1729_> Argument against changing the type system: 
09:19 < sanket1729_> The usage of `j` wrapper along with something that is `e` does not make much sense as the only use of `j` is to `f` type into `e`.
09:19 < sanket1729_> If you already have an `e` you should use it.
09:19 < sanket1729_> We are not losing much by marking as non-malleable as these scripts are already inefficient and it somehow tells the user to possible use a more efficient script without the `j` wrapper. 
09:19 < sanket1729_> Argument for changing the type system: More inclusive detection of non-malleable scripts.
09:21 < sanket1729_> And since it is not a correctness property, we can change it without affecting the existing things. 
09:24 < sanket1729_> I don't want to add new properties to the type system for this case, but if you think it is worth it I am not completely against it. 
09:26 < sanket1729_> Actually, it is not that much work to add this property, so I could go either way
16:40 < andytoshi> 13:41 < sanket1729_> andytoshi: Updating the code so that it only enforces the minimality for fuzzing roundtrip tests. When in non-fuzzing mode, we accept everything. 
16:40 < andytoshi> i don't like this :( i don't think we should accept things that are equivalent but less efficient than other things
16:41 < andytoshi> feels too much like "be liberal in what you accept"
16:41 < andytoshi> robertspigler: it was resolved in favor of leaving taproot as-is
16:41 < andytoshi> since it is already in progress to be deployed
16:41 < andytoshi> but probably in the direction of "we would've made another choice had we considered this a few years ago"
16:43 <@sipa> yeah, that's my takeway
16:44 <@sipa> i think it's a minor inconvenience (additional sanity checking that people may want to do on proposed script trees), but one we could easily have avoided if we had considered it
19:13 < robertspigler> sipa: andytoshi Thanks, makes sense
--- Log closed Sun Jul 25 00:00:16 2021