--- Log opened Sat Apr 24 00:00:35 2021 08:24 < andytoshi> iirc the leaf is committed in bip 341 08:26 < andytoshi> ah no, it's confusingly in the "ext" field, which is specified in BIP 342 to include tapleaf_hash, which is defined back in 341 08:26 < andytoshi> it's far too late for me to complain about this, but i find this detour from 341 into 342 and back kinda confusing to follow :) 08:35 < darosior> Was some more thought put into the discrepancy between the two compilers on thresh() ? It's going to become annoying to me as the HW i'm going to use took the approach of the C++ implem whereas i use the Rust implem :/ 08:37 < darosior> (Talking about https://github.com/rust-bitcoin/rust-miniscript/issues/241 ) 08:48 < andytoshi> :| i wonder if we should define a deterministic compiler 08:49 < andytoshi> the point of the compiler/policy language was that we wouldn't have these sorts of problems 08:51 < darosior> But here it's a difference in Miniscript itself? Like the HW would not be able to parse a Miniscript i give it 08:51 < darosior> Rather, it would consider it invalid 09:05 < jeremyrubin> andytoshi: so we can think about keys reused across branches, as long as branches are unique. That's great news! 09:06 < jeremyrubin> Unless there's some other satisfaction issue? 09:06 < jeremyrubin> andytoshi: as you know I +1 deterministic compiler :) 09:12 < andytoshi> not sure why sipa isn't in here 09:12 < andytoshi> i need him to sanity check that 09:12 < andytoshi> but i think you're right jeremyrubin 09:12 < jeremyrubin> I also spent a good amount of time confused btw 09:12 < jeremyrubin> about the ext_flag thing 09:13 < andytoshi> darosior: ah ok, but it looks like this is a bug in pieter's code not rust-miniscript? 09:14 < andytoshi> i asked sipa elsewhere to join. tho it's 9am on a saturday 09:15 < darosior> andytoshi: it's how it's defined on the website too :/ 09:15 < darosior> iirc you discussed it together here already 09:16 < andytoshi> oh i see i misread 09:16 < andytoshi> yeah i remember the discussion but not exactly where everything landed 09:16 < andytoshi> yeah ok we should fix this 09:16 < jeremyrubin> > 9am on a saturday 09:16 < andytoshi> in rust-miniscrpt 09:16 < jeremyrubin> bittcoin fixes this 09:16 < andytoshi> lol 09:16 < darosior> hehe 09:16 < jeremyrubin> IIRC sipa was upset and felt the entire type system needed to be rechecked? 09:16 < jeremyrubin> did he do that? 09:17 < darosior> Something like that yeah, if we decided to modify it . However it's a "simple" change on rust-miniscript side, i have a sketch of patch as draft PR 09:21 < jeremyrubin> rust-miniscript already supports tho, no? 09:27 < darosior> Yes, i meant the other way around: fixing rust-miniscript not Miniscript itself :) 09:28 < jeremyrubin> but rust-miniscript is OK? 09:28 < jeremyrubin> you want to patch the spec and c++ miniscript? 09:30 < jeremyrubin> btw andytoshi w.r.t. policy being deterministic, I think that it makes sense to have 2 policy compilers; one that makes not much of an effort at optimization but does *basic* type deduction for wrappers. Then one which does what I think you intended policy to be. 09:31 < jeremyrubin> the main issue with not using miniscript directly is that the wrapper types are kind of confusing to work with -- maybe this UX issue could be solved for Rust with a good set of From impls? 09:32 < andytoshi> i continue not to understand the "ux issue" here, either you have a valid miniscript or you don't. if you do there is zero ambiguity and shouldn't be any difference across platforms 09:33 < jeremyrubin> ah I see 09:33 < jeremyrubin> the main ux issue is that you find out at runtime if your miniscript is invalid 09:34 < jeremyrubin> whereas for policy it's a bit more "if it fits it ships" 09:35 < jeremyrubin> And the wrapping rules are just confusing to work with and a bit brittle 09:35 < jeremyrubin> E.g., if I want a miniscript that allows a user to pass in an arbitrary clause, but "wraps" it in an "or some multisig" 09:36 < jeremyrubin> i then need to implement all these deduction rules because I don't know what the user is going to input 09:36 < jeremyrubin> Policy solves *that* problem 09:36 < darosior> "but rust-miniscript is OK?" <= No, rust-miniscript differs from the C++ implem, the website and now Stepan's micropython implem. But on the other end it seemed like a thresh could have a threshold as high as the number of policies, but maybe not and it's either way easier to fix rust-miniscript. 09:36 < jeremyrubin> darosior: no, it's breaking change for rust-miniscript and I depend on that behavior 09:37 < jeremyrubin> darosior: the spec and c++ and micropython should be fixed 09:37 < darosior> What is the "fix" then? Changing Miniscript? The oversight is on us (rust-miniscript) :/ 09:38 < jeremyrubin> Yeah, you can PR a change to C++ miniscript and a change to the spec 09:38 < darosior> I don't know if it's the right thing to do. 09:38 < jeremyrubin> changing the spec is not surprising btw, it happened somewhat recently IIRC? 09:38 < darosior> Hence why i asked again here 09:39 < jeremyrubin> maybe the locktime thing didn't require a spec change, altho I would say the spec is therefore out of date w/ the code 09:40 < jeremyrubin> if you're feeling ambitous that would also be a good thing to document in a spec update :) 09:44 < darosior> Have you at least considered the implications of this change? I have not. Are you sure it does not break anything in the type system? Or a you recommending this only because fixing the mistake on our end would be a breaking change for you downstream? (for what it's worth it would be one for me, too) 09:45 < jeremyrubin> to the best of my ability I've tried to consider what impact there could be of making this change, and come up empty 09:45 < jeremyrubin> it seems that the main intent was "one way to do things" 09:46 < jeremyrubin> but in the interest of generating maximally efficient scripts in all cases, both forms should be allowed 09:47 < darosior> thresh(N, a, b, c,.. , n) will always be more efficient as and() s though? 09:48 < jeremyrubin> not nesc 09:48 < jeremyrubin> thresh requires b...n be Wdu 09:49 < darosior> I'm more concerned about thresh(1, a, b, c, .., n) because it makes the policy rewrites it as or() s which sanket1729 told me is exponential complexity. 09:49 < darosior> the policy compiler* 09:49 < jeremyrubin> so for example and_* can be more efficient in certain cases than wrapping 09:50 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined ##miniscript 09:50 < jeremyrubin> and_b for example "if both a and b are not 0, the outputs is 1, otherwise 0. 09:50 < jeremyrubin> whereas thresh requires that b be exactly 1 or 0 09:51 < jeremyrubin> so that wrapping can be more expensive 09:51 < darosior> I'm almost sure and() s are always more efficient, do you have a counter example of a policy that would be more optimal to compile to thresh(N, ...) than and() s? 09:51 -!- roconnor [~roconnor@host-45-58-225-218.dyn.295.ca] has quit [Ping timeout: 265 seconds] 09:51 < jeremyrubin> thresh(2, CLTV, CSV)? 09:51 < jeremyrubin> and_b(CLTV, CSV) 09:52 < jeremyrubin> one is just a booland 09:52 < jeremyrubin> the other is CLTV wrapped(CSV) ADD 2 EQUAL 09:53 -!- roconnor [~roconnor@host-45-58-195-183.dyn.295.ca] has joined ##miniscript 09:55 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Remote host closed the connection] 09:56 < jeremyrubin> andytoshi: i'm still trying to figure out which wrapper is required for the CSV fwiw haha, on my point about ux 09:58 < jeremyrubin> ah wait both older and after can't be used in and_b 09:58 < jeremyrubin> I think this might not invalidate my point though, I think thresh is still a bit less efficient because you need to specify the 2 equal 10:00 < jeremyrubin> i think you need dv:older() to convert to a Bdu from a Bz? 10:01 < jeremyrubin> hmm maybe not 10:01 < jeremyrubin> tbh (not trolling) i can't figure it out 10:02 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined ##miniscript 10:03 < jeremyrubin> i used policy: and_v(v:older(1000),v:after(2)) 10:05 < sipa> that's not a policy 10:05 < jeremyrubin> i used policy to compile and(older(1000), after(2)) rather than figuring it out by hand 10:07 < sipa> so which miniscript implementing that policy using thresh is more efficient than which other one that doesn't? 10:08 < jeremyrubin> ah I think I maybe read it backwards from what darosior said; i though he asked for the opposite 10:09 < sipa> i'd be very surprised if a 2-of-2 thresh is ever more efficient than using one of the and variants instead 10:09 < sipa> but on the other hand, i do think 2-of-2 thresh and and(..) should be seen as identical policy (unsure if it currently is) 10:10 < jeremyrubin> sipa: is there a reason why and(pk(A), thresh(2, older(10), older(1000), after(2))) should fail policy, but and(pk(A), thresh(3, older(10), older(1000), after(2))) is ok? 10:10 < jeremyrubin> oh right 10:10 < jeremyrubin> the duh 10:11 < jeremyrubin> (just trying to poke around to look at the outputs for this convo, forgot that the website is C++ based) 10:13 < darosior> sipa: it is partially on rust-miniscript, but completing it is part of the fix to have "strict thresholds" for thresh 10:18 < sipa> i see 10:19 < jeremyrubin> wait actually no it's vice versa... why would a thresh(2, a, b, c) fail policy but thresh(3, a, b, c) is ok? maybe the policy n-n to and is making the types work magically whereas otherwise older/after can't be in thresh 10:19 < jeremyrubin> I'm confused 10:23 < sipa> it may be due to other reasons 10:23 < sipa> perhaps it's malleable 11:54 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined ##miniscript 11:55 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection] 11:56 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined ##miniscript 14:16 -!- Netsplit *.net <-> *.split quits: jnewbery, justinmoon, jeremyrubin, RubenSomsen, midnight, meshcollider, darosior, sgeisler, digi_james, jonatack, (+18 more, use /NETSPLIT to show all of them) 14:17 -!- Netsplit over, joins: shesek, _0x0ff, jonatack, sanketcell, harrigan, darosior 14:18 -!- Netsplit over, joins: ghost43, jb55, sipa 14:18 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Max SendQ exceeded] 14:18 -!- Netsplit over, joins: robert_spigler, matt2 14:19 -!- Netsplit over, joins: meshcollider, rocket_fuel_ 14:19 -!- Netsplit over, joins: dr-orlovsky, willcl_ark_, mol, sanket1729 14:19 -!- Netsplit over, joins: RubenSomsen, midnight, michaelfolkson, justinmoon, jnewbery 14:20 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-htofrhqjoikorhcq] has quit [Ping timeout: 250 seconds] 14:20 -!- robert_spigler [robertspig@gateway/shell/matrix.org/x-kdqesaisvohrrlje] has quit [Ping timeout: 248 seconds] 14:20 -!- Netsplit over, joins: schmidty, sgeisler, appservicebot12 14:21 -!- roconnor [~roconnor@host-45-58-195-183.dyn.295.ca] has joined ##miniscript 14:21 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##miniscript 14:22 -!- RubenSomsen [sid301948@gateway/web/irccloud.com/x-hhsjnjpyzapmhanq] has quit [Ping timeout: 276 seconds] 14:22 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-uflnueqedawpmbec] has joined ##miniscript 14:23 -!- digi_james [sid281632@gateway/web/irccloud.com/x-zrxswqczsjtkfajj] has joined ##miniscript 14:26 -!- RubenSomsen [sid301948@gateway/web/irccloud.com/x-enkekiwnhjplxzfp] has joined ##miniscript 14:49 -!- robert_spigler [robertspig@gateway/shell/matrix.org/x-skoxfvjrvkkolcfy] has joined ##miniscript 15:29 -!- RubenSomsen is now known as Guest26781 15:29 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined ##miniscript 16:41 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection] 16:41 -!- shesek [~shesek@164.90.217.137] has joined ##miniscript 16:41 -!- shesek [~shesek@164.90.217.137] has quit [Changing host] 16:41 -!- shesek [~shesek@unaffiliated/shesek] has joined ##miniscript 16:47 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection] 16:47 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined ##miniscript --- Log closed Sun Apr 25 00:00:36 2021