--- Day changed Wed Jul 15 2020
01:26 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 246 seconds]     
02:16 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:d55c:34d1:9043:8e0c] has joined ##miniscript     
02:22 -!- jonatack [~jon@static-176-139-55-163.ftth.abo.bbox.fr] has joined ##miniscript     
02:35 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:d55c:34d1:9043:8e0c] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
03:09 -!- jonatack [~jon@static-176-139-55-163.ftth.abo.bbox.fr] has quit [Ping timeout: 258 seconds]     
03:27 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined ##miniscript     
04:27 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:d55c:34d1:9043:8e0c] has joined ##miniscript     
04:37 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:d55c:34d1:9043:8e0c] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
04:40 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:d55c:34d1:9043:8e0c] has joined ##miniscript     
06:13 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:d55c:34d1:9043:8e0c] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
06:18 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:d55c:34d1:9043:8e0c] has joined ##miniscript     
06:27 < andytoshi> if we put `sortedmulti` into miniscript, even top-level-only, it won't roundtrip to Script which will break our fuzztests
06:27 < andytoshi> sanket1729: i think having 3 descriptors is the way to go :/
06:28 < andytoshi> i'm also tempted to say "only WshSortedMulti"
06:28 < andytoshi> but i guess we ought to support everything core does
06:29 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:d55c:34d1:9043:8e0c] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
07:52 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:d55c:34d1:9043:8e0c] has joined ##miniscript     
08:27 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:d55c:34d1:9043:8e0c] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
08:38 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:d55c:34d1:9043:8e0c] has joined ##miniscript     
08:47 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:d55c:34d1:9043:8e0c] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
09:44 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:d55c:34d1:9043:8e0c] has joined ##miniscript     
10:32 < sanket1729> andytoshi: Btw, we also don't have descriptors for `addr` and `combo` from core. None of them are miniscript related, so I don't know if we should put effort into adding them. 
10:46 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:d55c:34d1:9043:8e0c] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
10:50 < andytoshi> i don't want combo
10:51 < andytoshi> addr we could add
10:51 < andytoshi> and raw
10:51 < andytoshi> actually idk how `addr` is supposed to work
10:51 < sipa> i agree combo is a pain, and probably was a mistake
10:52 < sipa> andytoshi: it's a nonsolvable descriptor, meaning it can't be used for signing or anything
10:53 < sipa> but as descriptors are nomimally a language for deriving scriptPubKeys, it makes sense for some interfaces (e.g. scan for outputs that match a certain descriptor) to be able to just say "scan for this address" with the same interface
10:53 < instagibbs> combo is not necessary really as three descriptors together cover them anyways
10:54 < sipa> four
10:54 < instagibbs> sortedmulti case was Coldcard, electurm et al all implemented it, and couldn't be supported
10:54 < sipa> pk, pkh, wpkh, sh(wpkh)
10:54 < instagibbs> ok, some existing subset :)
10:54 < instagibbs> nested hissss
11:00 < andytoshi> hmm sipa  .. so i think we don't want to support `addr` or `raw` actually in rust-miniscript
11:00 < andytoshi> because it would result in most of our functionality having to return a "not supported" error of some sort
11:01 < andytoshi> and i think users who need this functionality can emulate it without a ton of difficulty
11:01 < andytoshi> as we expose e.g. the names(and(parentheses)) parser
11:03 < andytoshi> though i can see the value in it, both the `.address()` and `.scriptpubkey()` methods would work on both
11:09 < jeremyrubin> API question: would it make sense to have Semantic policy be able to encode both PKH and PK so that you can lift from a script and store either depending on what you have? and then add a function which is "upgrade" that tries to map PKHs to PKs?
11:10 < jeremyrubin> Or should API wise this mapping always just be a separate map that gets passed around?
11:10 < jeremyrubin> It would seem nice to be able to upgrade a semantic policy -> semantic policy with all keys known
11:10 < jeremyrubin> And be able to write functionality expected to work only when keys are known
11:12 < andytoshi> sure, just make a key type whose assaciated Hash is the same as the original key
11:12 < jeremyrubin> That's interesting! Does that work well?
11:12 < andytoshi> i think maybe we should include a keytype in the library that does this
11:12 < andytoshi> because it's a super non-obvious use of the API
11:13 < andytoshi> yeah, it's a tiny bit unergonimic because you have to parse a Script to get a Miniscript<bitcoin::PublicKey>
11:13 < andytoshi> then use convert_pk or whatever it's called
11:13 < andytoshi> to change the bitcoin::PublicKey to the KeyWhoseHashIsTheKeyItself
11:13 < andytoshi> and then call .lift
11:14 < jeremyrubin> Interesting. It might also be a nice API move to change the type passed in from a Pk type to a AssociatedTypes type -- for the CTV support I'm working on one thing I'm debating is storing hashes v.s. storing the proposed transaction itself. It occured to me that the way PKH's are handled is the same question essentially
11:15 < andytoshi> i'm not sure i understand
11:16 < jeremyrubin> The script fragment for a CTV script is <H(tx)> CTV DROP, and if you lift from that you get CTV(H(tx)). But you might want to write a policy as CTV(tx) rather than CTV(H)
11:16 < jeremyrubin> A reason for that is wanting to be able to estimate redemption costs 
11:17 < jeremyrubin> So I could add another type to the Policy<Pk, Ctv>
11:17 < jeremyrubin> or it could be Policy<Types> and then use Types::Pk Types::Ctv
11:17 < andytoshi> ah i see
11:18 < andytoshi> so, a lot of our API (in particular the Satisfier trait) uses keys as keys
11:18 < andytoshi> so we can't generalize in this direction without breaking that
11:18 < jeremyrubin> I think you can actually!
11:18 < jeremyrubin> Because you can make a type which wraps a key type
11:18 < jeremyrubin> and the type is a key type with addition associated types
11:18 < andytoshi> hmmm
11:19 < andytoshi> this is tempting
11:19 < jeremyrubin> So the default thing it is is a key, but you could add other key associated info
11:19 < jeremyrubin> I think that actually already works decently
11:19 < sipa> fwiw, in the c++ signer logic, keys are just pubkeyhashes
11:19 < andytoshi> though i think it will result in a more complicated and unergonomic API for peope using vanilla Script
11:19 < sipa> such miniscripts can't be converted to script, but it's also not needed
11:19 < andytoshi> jeremyrubin: out of curiousity, if you try to impl MiniscriptKey on bitcoin::Transaction what problems do you run into?
11:19 < andytoshi> like, could you just use the existing API?
11:20 < jeremyrubin> Well the issue I would have is that I want CTV and Pks
11:20 < andytoshi> i guess not because you won't be able to serialize to Script(+CTV)
11:20 < andytoshi> right i see
11:20 < jeremyrubin> FYI https://github.com/JeremyRubin/rust-miniscript/pull/1 works
11:20 < andytoshi> it's not clear to me what we can do there
11:21 < jeremyrubin> But you just have opaque hash types, which is not ideal. I think associated types with a trait default works well?
11:22 < jeremyrubin> Then anything that already exists has a type that can fail if attempted to be used
11:23 < andytoshi> so, it works if you want to change Miniscript<Pk> to Miniscript<Pk, Ctv> in your fork
11:23 < andytoshi> I think that's a good idea actually
11:23 < andytoshi> but like, for rust-miniscript (the mainline one) i don't think there's any API change we can make to make your life easier?
11:23 < jeremyrubin> Well there are two things that are different
11:23 < jeremyrubin> This change should be upstreamable
11:24 < jeremyrubin> whereas the determinism stuff does not need to be
11:24 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:d55c:34d1:9043:8e0c] has joined ##miniscript     
11:24 < andytoshi> well if you're adding another type parameter just for use in CTV descriptors, that's not really upstreamable :)
11:24 < andytoshi> because we don't have CTV descriptors upstream
11:24 < jeremyrubin> upstream + upstream^2 able
11:25 < jeremyrubin> I think one day upstream^2 will be there for CTV or something very similar, and the miniscript machinery won't change much
11:26 < jeremyrubin> so trying to figure out what the idiomatic approach is so that things downstream from this fork (e.g. Sapio project) won't need to diverge on API
11:26 < jeremyrubin> I agree for my project if never upstreaming adding a type param is easy
11:27 < jeremyrubin> If ctv descriptor is upstream^2'd, is a type parameter then easy to add upstream?
11:27 < andytoshi> yep     
11:27 < andytoshi> upstream^2 being bitcoin?
11:27 < andytoshi> or Core or whatever
11:28 < jeremyrubin> Well it's whatever you are referring to not having CTV descriptors, having CTV descriptors 
11:28 < andytoshi> though it's hard to imagine Core having a CTV descriptor without bitcoin having CTV :)
11:28 < andytoshi> gotcha
11:28 < jeremyrubin> Well sure, I'm trying to build out the software support for that to demonstrate what functionality CTV brings
11:28 < jeremyrubin> and want to be able to show an end-to-end picture
11:29 < jeremyrubin> So I think i may have already added descriptors for ctv in my worktree somewhere, will double check
11:32 < jeremyrubin> Anyways thanks for answering my questions, in summary:
11:33 < jeremyrubin> 1) Would be cool to document "identity hashtype of keys" somewhere
11:33 < jeremyrubin> 2) Will add CTV support using a separate type parameter (rather than associated) if I want to be able to lift to different types with a translator
11:35 < jeremyrubin> 3) Miniscript support for this should be *after* upstream descriptor support.
11:36 < andytoshi> yeah that all sounds correct/reasonable
12:01 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:d55c:34d1:9043:8e0c] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
14:57 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:d55c:34d1:9043:8e0c] has joined ##miniscript     
15:30 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:d55c:34d1:9043:8e0c] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
18:59 -!- jeremyrubin [~jr@2601:645:c200:f539:6825:208:c554:712b] has quit [Ping timeout: 256 seconds]     
20:16 -!- shesek [~shesek@5.22.128.126] has quit [Read error: Connection reset by peer]     
20:16 -!- shesek [~shesek@5.22.128.126] has joined ##miniscript     
23:10 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:d55c:34d1:9043:8e0c] has joined ##miniscript     
23:20 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 260 seconds]     
23:25 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:d55c:34d1:9043:8e0c] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]