--- Log opened Thu Dec 31 00:00:03 2020
00:17 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]
00:31 -!- shesek [~shesek@164.90.217.137] has joined ##miniscript
00:31 -!- shesek [~shesek@164.90.217.137] has quit [Changing host]
00:31 -!- shesek [~shesek@unaffiliated/shesek] has joined ##miniscript
05:26 < michaelfolkson> I missed this originally. andytoshi comment on https://bitcoin.stackexchange.com/questions/100413/for-a-redeem-script-to-satisfy-the-conditions-of-a-script-what-must-it-leave-on
05:26 < michaelfolkson> Yes, if there are unbalanced IF and ENDIF then the script will fail. Similarly if you use ELSE outside of any IF statement. (Curiously, you can use multiple ELSE statements in a row, and the interpreter will just execute all the odd/even ones depending on the input to the IF
05:27 < michaelfolkson> What exactly is input to the IF so that the interpreter only executes the odd/even ELSEs?!
05:29 < aj> michaelfolkson: 1 IF x ELSE y ELSE z ELSE a ENDIF will execute x and z; if it'd been 0 instead, it'd do y and a. ELSE just swaps execution from off to on or vice-versa
05:31 < michaelfolkson> Thanks aj. Is there a rationale for it doing that? Or is it just a weird bug?
05:31 < aj> it's just an implementation quirk
05:41 < michaelfolkson> The expected behavior would be that it executes y, z and a assuming the IF is false?
05:44 < michaelfolkson> I guess the way it works makes sense. Doesn't make much sense to use multiple ELSEs. Use ELSEIFs if you not a boolean condition
07:31 < andytoshi> yeah i've never found a use for multiple ELSEs
07:32 < andytoshi> it's not like you can execute anything in between the odd/even blocks, so you might as well just combine them into two like a normal person
07:52 < sipa> i think this was just easier to implement
07:52 < andytoshi> sanket1729: your latest commit doesn't compile for me
07:52 < andytoshi> cargo +stable  build  '--no-default-features' '--features=compiler use-serde rand' # 2020-12-31T15:50:42 / cargo 1.48.0 (65cbdd2dc 2020-10-14)
07:57 < sanket1729> Looking at it
08:54 < andytoshi> lol that if you somehow force an uncompressed key into a segwit descriptor it'll refuse to give you an address for it
09:10 -!- jonatack [~jon@104.254.90.235] has quit [Ping timeout: 256 seconds]
09:11 < sanket1729> I don't think it's possible to force it. 
09:12 -!- jonatack [~jon@134.19.179.179] has joined ##miniscript
09:13 < andytoshi> yeah, it's fine, we shouldn't force it, you can't create such a descriptor if you're using the API properly so the user should expect weird things
09:13 < andytoshi> this is just a particularly funny form of weirdness
09:15 < sanket1729> I have updated the PR. 
09:22 < andytoshi> yep, looks good! 2 more commits to test and then i can merge
09:23 < andytoshi> i am going to make a followup MR which tries to remove ToPkCtx, and which maybe tries to improve the PkTranslate trait to make it more ergonomic
09:25 < andytoshi> our goals with ToPkCtx were (1) to let users avoid the hard-to-call translate_pk method; (2) some slight efficiency improvement where they could compute addresses etc without creating a whole copy of the descriptor
09:26 < andytoshi> and (3) to have a prettier API for "get the nth address from a ranged descriptor"
09:27 < andytoshi> but (1) i think we can improve by adding some extra methods to PkTranslate .. (2) i think was never that valuable ... i'm not sure what kind of system can't spare a few kb for a new descriptor copy, but is willing to do expensive EC ops ... and anyway you can achieve this if you really want to by creative use of RefCells
09:28 < andytoshi> and (3) i think we simply failed on, because "get the nth address" is not always possible, e.g. if we have a path with hardened path segments and we have no secret data
09:29 < andytoshi> so the resulting API is both annoyingly restrictive and it's not even panic-free
09:38 < sanket1729> For 2), it was about creating a secp context, not a copy of descrpitor
09:38 < andytoshi> how could ToPkCtx avoid creating a secp context?
09:39 < sanket1729> The ToPublicKey API needed additional parameters for taking in a secp reference
09:39 < sanket1729> If we don't have that parameter, we need to create a context each time
09:39 < sanket1729> Ah, RefCell
09:40 < sanket1729> Are you saying that it is possible with some clever MiniscriptKey implementations?
09:41 < sanket1729> Ah, nevermind. 
09:43 < sanket1729> andytoshi: Do you plan to do (1) by differentiating descriptors before and after derivation?
09:43 < sanket1729> in the type system
09:46 < sanket1729> I don't completely understand how you are doing it :P, I will wait for the MR
09:49 < andytoshi> sanket1729: ah yeah i see what you're saying. yeah, give me a bit of time to work through this :P
09:49 < andytoshi> i'm sure we can do better than having these NullCtxs everywhere
09:49 < sanket1729> yeah, no hurry
11:48 -!- felixweis [sid154231@gateway/web/irccloud.com/x-jtweehemopgkzarw] has quit [Ping timeout: 260 seconds]
11:50 -!- felixweis [sid154231@gateway/web/irccloud.com/x-ammtqmswwvkhmxzx] has joined ##miniscript
19:04 -!- willcl_ark [~quassel@cpc123780-trow7-2-0-cust177.18-1.cable.virginm.net] has quit [Quit: No Ping reply in 180 seconds.]
19:07 -!- willcl_ark [~quassel@cpc123780-trow7-2-0-cust177.18-1.cable.virginm.net] has joined ##miniscript
--- Log closed Fri Jan 01 00:00:02 2021