--- Log opened Thu Apr 28 00:00:08 2022
01:55 < sanket1729_> darosior: Finally completed the post merge review 24147. Left some comments about bugs/issues
02:00 -!- robertspigler [~robertspi@2001:470:69fc:105::2d53] has quit [Quit: You have been kicked for being idle]
02:30 < darosior> I agree that not considering pkh(H) a descriptor (as the current BIPs, documentation and website do) and instead having an explicit way to convey partial information (rawpkh) is the way to go. We all seemed to agree on the Bitcoin Core issue tracker discussion anyways?
02:32 < darosior> I am a bit confused with sipa's reasoning on "pk_h(H) is stil 'd'". It seems to me that a property is deduced from the actual Bitcoin Script, and here the Script tells you that you can't dissatisfy without a secret. I don't mean to restart the discussion, i understand the distinction you want to make with the Miniscript type system.
02:32 < darosior> sanket1729_: awesome, thanks!
03:46 < sanket1729_> darosior: pk_h(H) is not a descriptor. 
03:46 < sanket1729_> raw_pkh(H) could be(not yet decided)
03:47 < sanket1729_> And whenever you see any raw in your descriptor, you don't analyze anything because you don't have the full picture
03:50 < darosior> I was not saying the contrary?
04:15 < sanket1729_> Sorry, I did not read the first comment
04:16 < sanket1729_> 4:00 am kicking in
04:19 < darosior> :)
04:20 < darosior> andytoshi: "otoh, the only key type we provide, DescriptorPublicKey, does have this hash==pk property" -> we also provide bitcoin::PublicKey for which hash==hash160(pk)
04:21 < darosior> Sorry if it sounds like i'm scaremongering. Hopefully this repro helps https://github.com/rust-bitcoin/rust-miniscript/issues/368#issuecomment-1112083095
05:26 < andytoshi> darosior: no, you're not scaremongering, it's just taking me some time to wrap my head around the issue
05:26 < andytoshi> i think it is a real issue but i'm not sure how to approach it
05:27 < andytoshi> maybe once we have partial descriptors that will give us the right framework
05:27 <@sipa> I think it will make it easier.
05:28 <@sipa> Because it brings things into scope of miniscript/descriptors itself.
05:30 < darosior> Yes, in the meantime we can just make "hash == Pk" for bitcoin::PublicKey too. Then the user can't shoot themselves in the foot with the types provided by the libraries. Once we have "rawpkh()" we can probably even get rid of the custom hash type trick
07:27 -!- stickies-v [sid544753@id-544753.uxbridge.irccloud.com] has joined ##miniscript
07:31 < stickies-v> in the doc of script/miniscript.h, the Nonzero property is described as "For every way this expression can be satisfied, a satisfaction exists that never needs a zero top stack element." I'm confused by the phrasing of the second part. Does it mean that this satisfaction does not not consume anything from the stack, or simply that it doesn't need the top stack element to be zero?
07:32 < stickies-v> Contextually I'd assume the first, but for a literal interpretation I'd lean more towards the second. Or, a third option?
07:33 <@sipa> the website says: "n" Nonzero: this expression always consumes at least 1 stack element, no satisfaction for this expression requires the top input stack element to be zero.
07:34 < stickies-v> "does not not consume" should just be "does not consume", sorry
07:34 <@sipa> So put otherwise: a satisfaction always exists which consumes one or more elements from the stack, and the first one of those is nonzero.
07:41 < stickies-v> okay that helps, thanks. I'm currently going through miniscript.h and making some small typo/grammar/suggestion fixes in the documentation. I'll compare with https://bitcoin.sipa.be/miniscript/ and update if I see any meaningful differences.
07:43 <@sipa> The website is in https://github.com/sipa/miniscript/blob/master/index.html, FWIW
07:43 <@sipa> if you wanted to make changes there too
07:43 < stickies-v> will do
08:35 -!- proofofkeags_ [~proofofke@96-81-42-77-static.hfc.comcastbusiness.net] has joined ##miniscript
08:57 -!- salvatoshi [~salvatosh@genymobile-2-6-86.fib.nerim.net] has quit [Ping timeout: 256 seconds]
09:54 -!- salvatoshi [~salvatosh@lfbn-idf3-1-717-163.w86-252.abo.wanadoo.fr] has joined ##miniscript
10:19 -!- salvatoshi [~salvatosh@lfbn-idf3-1-717-163.w86-252.abo.wanadoo.fr] has quit [Ping timeout: 260 seconds]
12:29 -!- salvatoshi [~salvatosh@lfbn-idf3-1-717-163.w86-252.abo.wanadoo.fr] has joined ##miniscript
13:46 -!- salvatoshi [~salvatosh@lfbn-idf3-1-717-163.w86-252.abo.wanadoo.fr] has quit [Ping timeout: 246 seconds]
17:27 -!- proofofkeags_ [~proofofke@96-81-42-77-static.hfc.comcastbusiness.net] has quit [Ping timeout: 240 seconds]
23:51 -!- salvatoshi [~salvatosh@genymobile-2-6-86.fib.nerim.net] has joined ##miniscript
--- Log closed Fri Apr 29 00:00:08 2022