--- Day changed Wed Sep 16 2020
01:07 -!- midnight [~midnight@unaffiliated/midnightmagic] has quit [Ping timeout: 244 seconds]     
01:11 -!- midnight [~midnight@unaffiliated/midnightmagic] has joined ##miniscript     
02:46 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection]     
02:46 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined ##miniscript     
03:23 -!- jonatack [~jon@37.166.247.142] has quit [Read error: Connection reset by peer]     
06:07 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined ##miniscript     
10:35 < darosior> sgeisler: are you around ?
10:37 < darosior> Hmm nevermind finally
13:00 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection]     
13:00 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined ##miniscript     
14:13 < sgeisler> sanket1729, andytoshi: darosior found an interesting footgun in my derivable descriptor idea. One way to fix it would be to use actual keys instead of key hashes in `pkh()` nodes (like for `pkh` descriptors). Do you think that's a good idea?
14:13 < sgeisler> https://github.com/rust-bitcoin/rust-miniscript/pull/131#discussion_r489643254
14:14 < sipa> when you're inferring a miniscript from script you don't have the key
14:15 < sipa> (but you also don't need it for all use cases - e.g. satisfactions that don't include a signature with that key)
14:18 < sipa> oh, sorry, this is about pkh descriptors, not miniscript
14:18 < sgeisler> Ah, right, that would make the type more annoying (optional key) :/ But deriving wouldn't make any sense on such a miniscript anyway, so it wouldn't be a blocker  in general imo
14:18 < sgeisler> no, you were right, the first pkh was about miniscript nodes
14:19 < sgeisler> I didn't think about parsing it from script
14:20 < sipa> it probably doesn't matter for pkh outputs, as there is only a single signer
14:20 < sipa> so if you don't have the key, you can't do anything with it anyway
14:23 < sgeisler> yeah, but we probably don't want parsing to require a hash-key map, so if I need the key to a hash for deriving a miniscript based descriptor I need it to be `(Hash, Option<Key>)` or I have to supply a hash-key map when deriving (also annoying).
14:23 < sgeisler> *parsing miniscript from script
14:24 < sipa> in core, signing uses data strcutures instantiated with keyhash as key type
14:25 < sipa> which always permits parsing, and can sign with the keys you actually have (in a lookup map)
14:25 < sipa> derivation/descriptors uses an instantiation with full keys, which can't be parsed from script
14:27 < sgeisler> I guess I could just add another type parameter to specify if hashes are hashes or actually keys and impl parsing from script only for the former and derivation only for the latter
14:27 < sipa> i maintain that you only need one type parameter :p
14:31 < sgeisler> By treating hashes as keys that are maybe just hashes or possibly more for parsing (`KeyOrHash`) but always have to be actual keys for derivation (`Key`)? I think our current traits already support that, sounds great!
14:33 < sipa> no, for signing *all* keys (whether those in pk, pkh, ...) are represented as hashes, and you can't convert to string, or derive addresseswith it - but you can sign
14:34 < sipa> in descriptors and for derivation, *all* keys (whether in pk, pkh, ...) are represented as full public keys; this means you can't parse without lookup table, but for derivation you don't nedd that
14:34 < sipa> i know andytoshi has a different opinion on this, though
14:36 < sgeisler> I see, I wonder if that will haunt us when finalizing PSBTs, that's the only other place apart from signing where we need to reconstruct a miniscript to run the satisfier. I don't see a problem as we should have all these maps too at that point, but I haven't worked much with it.
14:37 < sipa> yes, and a wider point: for p2sh/p2wsh you need a map from script hashesto scripts anyway, or you don't even have a script to work with
14:37 < sipa> it seems reasonable to treat keys the same way
15:37 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]     
15:50 < andytoshi> sgeisler: i think it's reasonable, when working with psbts, to require that you have the hash→key map filled in
15:50 < andytoshi> i.e. do the "require a lookup table and fail if you don't have one"
15:50 < andytoshi> specifically for working with PSBTs
15:51 < andytoshi> Hmm, or alternately we could interpret a pkh output as a bare(pkh(H)) rather than as a pkh descriptor
15:52 < andytoshi> which i think would allow parsing
15:55 < andytoshi> without the table