--- Log opened Wed Aug 04 00:00:29 2021
02:44 < darosior> andytosh1, sanket1729: am i missing something or we parse in rust-bitcoin pk_h(xxx) as containing a hash whereas it should (according to the specs) contain a key?
02:45 < darosior> And the C++ implem parses it as containing a key
04:30 -!- roconnor [~roconnor@host-184-164-31-32.dyn.295.ca] has joined ##miniscript
06:33 < andytosh1> it takes a Pk::Hash
06:34 < andytosh1> if you want to parse sipa-style descriptors just use a key type, like DescriptorPubKey, where Pk::Hash == Pk
06:36 < andytosh1> that is interesting that the spec says "key" there, i didn't realize that you actually can't parse Script into miniscript using the spec
06:36 < andytosh1> even if you're not trying to emulate Core
06:36 < andytosh1> IMO that's a bug
06:36 < andytosh1> in the spec
06:50 < darosior> Oh yeah i forgot about the Pk::Hash == Pk trick
06:50 <@sipa> andytosh1: you know my opinion
06:52 < darosior> I'm currently working on a Python implementation and i wonder which road to take
06:52 < darosior> sipa: what was your opinion? I must have read it here but forgot
06:53 <@sipa> in my view, you shouldn't see scripts/miniscript in isolation; in pracice you have context, like a scriptpubkey to redeemscript map for p2sh
06:54 <@sipa> descriptors encode all information needed to spend an output, which for pk_h implies the full key
06:54 <@sipa> and thus it isn't unreasonable to say that when persing a pk_h into a descriptor, you also need a pkh -> pk map
06:57 <@sipa> in *miniscript* (as an abstract framework, outside of descriptorsland), there may be cases where you want to be able to parse things without having all that information available, but then you also can't (and i suspect don't need) to convert to a descriptor notation
06:59 < darosior> Hmm, then we could mark in the specs pk_h as taking either a key or hash160?
06:59 <@sipa> grrrrrrrrr
06:59 <@sipa> nkbody fucking gets i5
06:59 -!- sipa [~pw@user/sipa] has left ##miniscript []
07:00 -!- sipa [~pw@user/sipa] has joined ##miniscript
07:00 -!- mode/##miniscript [+o sipa] by ChanServ
07:00 <@sipa> no
07:00 <@sipa> that's the oppositiw of what i said
07:00 <@sipa> descriotors encode all informa6ion to spend an output
07:00 <@sipa> a pk_h descriptor with a pubkeyhash only is NOT a descriptor
07:01 <@sipa> it makes sense in the miniscript framework when doing signing/analysis, but that's unrelated to descriptors
07:01 < darosior> Ok, i was refering to your last sentence for parsing it in Miniscript outside of descriptorland
07:01 <@sipa> that doesn't need a spec
07:02 < darosior> So the spec at http://bitcoin.sipa.be/miniscript/ is for Miniscript *in descriptor context*?
07:03 <@sipa> well it lists descriptor fragments
07:03 <@sipa> the word "pk_h" is desceiptor language
07:05 < darosior> Ok, i must be misunderstanding the distinction between Miniscript and Descriptors then. I thought about Miniscript as being "contained by" Output Descriptors
07:06 <@sipa> yes
07:06 <@sipa> in that context there is no distinction between them
07:07 <@sipa> see miniscript as a project to extend the descriptor language and its functionality with (significantly) more complex scripts
07:08 <@sipa> and the pk_h() fragment there takes a key expression (i.e., a pubkey, an xpub, derivation, ... )
07:10 <@sipa> but miniscript as a framework/codebase does more than just defining descriptors - it gives a way to reason about scripts, and analyze their policy, or participate in generic signing
07:12 <@sipa> so if you want to have a reusable codebase that can do those things, perhaps it makes sense that that codebase can be used in a mode where it can represent scripts with things like keys for which only the pubkeyhash is known
07:12 <@sipa> this is true for both the rust and c++ implementations, with somewhat different levels of parametrization of keys
07:14 <@sipa> (iirc in rust-miniscript, pk_k and pk_h have different type argumemts for their key type; in C++ they're the same)
07:15 <@sipa> darosior: my apologies for my reaction earlier, that was inappropriate
07:15 < darosior> No worries
07:16 < darosior> However i just tested and the C++ implem can't parse a pk_h(<insert hash160 here>)
07:17 <@sipa> it can't *parse* it no, because it parses descriptors, and that is not a descriptot
07:17 <@sipa> it can represent them, though
07:17 < darosior> Ok
07:18 <@sipa> but so my view is: yes, you can't parse *just a script* into a pk_h descriptor, but in my view, this is also arbitrary and useless functionality; you don't ever *have* just a script; if you did, you'd need to continie that reasoning and expect you can parse a descriptor out of just a scriptPubKey
07:19 <@sipa> (which you can with raw/addr descriptors, but they're severely limited in functionality)
07:22 <@sipa> so requiring that at parsing time of a scriptpubkey you have a scripthash->redeemscript hash (which is obviously necessary) isn't different from requiring that you have a pubkeyhash->pubkey lookup mechanism as well
07:39 <@sipa> perhaps it would be useful to consider explicitly accomodating "partial information" as something that's supported in descriptors, but then it should be done consistently too (e.g. support a raw descriptors inside sh(), to deal with the case where you know an output is P2SH, but nothing more)
07:40 <@sipa> for tr() that may be even more useful
07:40 <@sipa> when subtrees may be hidden
09:39 < darosior> sanket1729: fyi https://github.com/rust-bitcoin/rust-miniscript/issues/260
10:10 < darosior> sanket1729: for the above ^ Sorry, was (again) confused.
10:11 < darosior> But there is definitely something wrong with lift() :p
10:11 < sanket1729> I was investigating the code. 
10:11 < sanket1729> Nice, so the compiler is expected output, but the lifting is not representing the correct thing?
10:12 < darosior> Yep i think i just found it
10:12 < darosior> Here https://github.com/rust-bitcoin/rust-miniscript/blob/5193fa49e00ad3a48fde6bc775f674f5c47976b7/src/policy/mod.rs#L146-L152
10:12 < darosior> b and c are mixed up, i think
10:12 < sanket1729> Yep
10:12 < sanket1729> Right
10:48 < darosior> Fix is up https://github.com/rust-bitcoin/rust-miniscript/pull/261 :)
14:13 -!- gene_ [~gene@2a0a:3840:1337:127:0:b9c1:7fec:1337] has joined ##miniscript
14:14 -!- gene_ is now known as gene
14:29 -!- roconnor [~roconnor@host-184-164-31-32.dyn.295.ca] has quit [Ping timeout: 250 seconds]
17:38 < sanket1729> I was trying to figure out the typing rules for the property say "y" which is basically "n" but with the additional requirement "all unconditional dissatisfactions for this expression require the top input stack element to be zero."
17:39 < sanket1729> This is kindof awkward because calculating recursively this requires 'z' property (which is classified as correctness property), but this new "y" is malleability one
17:40 < sanket1729> Sort of breaks the nice clean separation of correctness/malleability properties we have.
17:42 <@sipa> i don't think that's really a problem
17:42 <@sipa> but i also don't know if ut's worth changing the type system for
17:43 < sanket1729> yup, I tend to agree.
17:52 < sanket1729> Can you re-review at PRs in sipa/miniscript when you have time? 
17:52 <@sipa> yeah, i will!
19:12 -!- andytosh1 is now known as andytoshi
--- Log closed Thu Aug 05 00:00:29 2021