--- Day changed Fri Sep 25 2020
01:48 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]     
01:48 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined ##miniscript     
02:54 -!- jonatack [~jon@37.164.166.21] has joined ##miniscript     
03:18 -!- jonatack [~jon@37.164.166.21] has quit [Ping timeout: 240 seconds]     
03:19 -!- jonatack [~jon@109.202.107.10] has joined ##miniscript     
05:12 < andytoshi> just reading scrollback now
05:13 < andytoshi> what if we introduced a `?` which had to be 0 or 1, could appear anywhere in the path, and left * alone (always means a list, only appears at the end)
05:13 < andytoshi> is this too close to blessing the "0/1 means change" workflow?
05:15 < andytoshi> as an alternate sgeisler i think you could just define your own keytype for your wallet, making sure the syntax didn't conflict with normal descriptors. we do this in liquid where our functionary descriptors have "keys" which are literally ascii name strings identifying functionaries
05:15 < andytoshi> or just deal with the duplication :P
07:06 -!- jonatack [~jon@109.202.107.10] has quit [Ping timeout: 272 seconds]     
08:53 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]     
08:53 -!- ghost43_ [~daer@gateway/tor-sasl/daer] has joined ##miniscript     
09:50 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined ##miniscript     
09:54 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Quit: Bye]     
09:56 -!- achow101 [~achow101@unaffiliated/achow101] has joined ##miniscript     
09:58 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Client Quit]     
10:00 -!- achow101 [~achow101@unaffiliated/achow101] has joined ##miniscript     
10:35 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Quit: Bye]     
10:35 -!- achow101 [~achow101@unaffiliated/achow101] has joined ##miniscript     
10:38 < sanket1729> andytoshi: What do you mean "this is fixed" in https://github.com/rust-bitcoin/rust-miniscript/pull/121#discussion_r495120832 ? 
10:38 < andytoshi> i mean you need to replace [bool; 5] with a real type
10:38 < sanket1729> I can raise another PR for policy language time specification.
10:38 < sanket1729> I did that
10:39 < andytoshi> oh, sorry, i didn't see it
10:39 < andytoshi> in the total diff on the PR there is still [bool; 5]
10:39 < sanket1729> interesting. Should not be there
10:39 < andytoshi> ah it is only on one function
10:41 < sanket1729> I am going through diff. I don't see it, which commit?
10:41 < andytoshi> https://github.com/rust-bitcoin/rust-miniscript/pull/121/commits/50b06d733d2d4cd338b86e98cb92a1e27133306f
10:42 < andytoshi> check_timelocks_helper
10:42 < sanket1729> Nice catch. I will fix that
10:45 < darosior> andytoshi: not sure i get "just make the MiniscriptKey::Hash type for DescriptorPublicKey be DescriptorPublicKey"
10:45 < darosior> Could you expand a bit ?
10:45 < darosior> https://github.com/rust-bitcoin/rust-miniscript/pull/131#issuecomment-699041153
10:46 < andytoshi> darosior: in the impl of the Miniscript trait
10:46 < andytoshi> write `type Hash = Self`
10:46 < darosior> Yep, got that
10:47 < andytoshi> then in anything that is impl'd on Miniscript<DescriptorPublicKey>
10:47 < andytoshi> or Descriptor<DescriptorPublicKey>
10:47 < andytoshi> you will have access to the key even in PkH
10:47 < andytoshi> are you trying to .derive() on something more generic than that?
10:48 < darosior> No, ok got it. Nice thanks
10:48 < sipa> andytoshi: that ? means that effectively every descriptor becomes an description of "two lists of scriptPubKeys" - i don't think that's any better; in many situations that makes no sense, and means every user needs to have an idea what those two lists mean
10:50 < andytoshi> not every descriptor, just the ones that have ?s in them :P
10:51 < sipa> ok, "up to" 2 lists
10:51 < andytoshi> yeah, i get your point
10:51 < andytoshi> well, i'm not sure i do tbh .. why is "up to 2" any more complicated than "up to 1"?
10:52 < sipa> i can't see how you could think any different
10:52 < sipa> of course it is
10:52 < sipa> what does two lists mean?
10:53 < sipa> what semantics do they have?
10:53 < sipa> how do you explore them?
10:53 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Read error: Connection reset by peer]     
10:53 -!- achow101 [~achow101@unaffiliated/achow101] has joined ##miniscript     
10:55 < andytoshi> the same as you explore one list
10:55 < andytoshi> but twice
10:55 < andytoshi> it's a small constant multiplier on the complexity
10:55 < sipa> i think it works fine if you're going to introduce different classes of descriptors, e.g. for importing in a watch-only wallet or scantxoutset you'd reject any descriptor with a ? in it, but for defining a new wallet, you'd need one that does have two
10:56 < sipa> but i think this is a bad idea
10:56 < andytoshi> kk     
10:56 < sipa> it means you can't take a descriptor of one type and use it in the other, needing a conversion step, breaking the checksums, ...
11:00 < sipa> maybe it makes sense to have something like a "templated descriptor" for extending, where you introduce variable names in the syntax, and they variables first need an assignment to expand into a real descriptor
11:00 < andytoshi> for both watch-only wallets and scantxoutset it seems like the behavior would be to scan both lists
11:01 < sipa> e.g. wpkh(xpub/.../$CHANGE/*), which you could turn into a descriptor using CHANGE=0 or CHANGE=1
11:01 < sipa> andytoshi: but that's not inherent, there is no special meaning two having two lists; you could specify scanning/importing both
11:02 < sipa> and having just a single one makes just as much sense
11:02 < sipa> e.g. you only want to scan for payments to the public chain
11:02 < sipa> so now if you want to do that, you can't use the same descriptor anymore
11:03 < andytoshi> ah yeah i see your point
11:03 < andytoshi> the change/nonchange lists are conceptually separate and a ? operator conflates them
11:03 < sipa> right, there are two reasons why you'd want the ?... one is just avoiding reuse, which is a good reason i think, and i don't have a good solution for
11:04 < sipa> but it seems what you're suggesting is attaching specific semantics to what 0 and 1 mean in many contexts, and as those only make sense in some, i'd prefer to keep those semantics out
11:18 < darosior> andytoshi: but to_pubkeyhash() cannot be implemented correctly ? The compiler, satisfier etc.. Will all get a pubkey where they expect a pubkeyhash
11:18 < darosior> Since it returns Self::Hash 
11:22 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 260 seconds]     
12:01 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined ##miniscript     
12:02 -!- ghost43_ [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]     
12:03 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined ##miniscript     
12:20 < andytoshi> darosior: i don't see why the exact type would make any difference
12:21 < andytoshi> just implement to_pubkeyhash() as an identity function
12:21 < andytoshi> if this causes problems anywhere then that's a bug
12:21 < darosior> Argh
12:21 < andytoshi> sipa: i don't mean to attach specific semantics, i just mean to widen the set of scriptpubkeys which are described by a given descriptor
12:21 < andytoshi> but i see where you're coming from. tbh i don't feel too strongly about having ?
12:21 < andytoshi> vs just having multiple descriptors
12:21 < darosior> Implemented a placeholder type
12:23 < andytoshi> a placeholder type?
12:23 < darosior> Hmm i don't see how this could not pose a problem, eg just thinking about Display'ing the policy
12:23 < darosior> DescriptorPublicKeyHash { hash, publickey }
12:23 < darosior> And in MiniscriptKey:
12:23 < darosior> type = DescriptorPublicKeyHash
12:24 < darosior> So that we can use the hash for to_pubkeyhash() and the pubkey when deriving
12:25 < andytoshi> i'm really confused as to why this is necessary
12:25 < andytoshi> and why you can't just use the identity
12:25 < darosior> Will try..
12:25 < andytoshi> i mean, if you want Display to output a hash then i guess you need a separate type .. but then from_str will be impossible to implement
12:25 < andytoshi> unless you have *only* the hash, in which case .derive will be impossibel
12:26 < andytoshi> i also don't see the value in Display outputting a hash tbh
12:27 < darosior> Yeah, i just assumed you used it internally for other things as well
12:27 < andytoshi> the trait bounds on Pk::Hash define the only things that the hash type needs to satisfy
12:27 < darosior> Given the name of the function, it seemed weird to me to make "to_pubkeyhash" return actually a pubkey
12:27 < andytoshi> and i designed this trait assuming people would use the identity function for a lot of types
12:28 < andytoshi> the identity function is a hash function, under a broad enough definition :)
12:28 < andytoshi> it's collision-resistant and has a constant-sized output (for constant-sized input ;))
12:28 < darosior> Haha ok, doing that now
12:29 < sipa> andytoshi: and for sufficiently random input, its output is indistinguishable from random ;)
12:29 < andytoshi> hahah
12:30 < andytoshi> in seriousness though, the Hash trait is so-named because the typical use is for bitcoin::PublicKey and hash160::Hash .. but as you can tell from the trait bounds it isn't actually required to be a "hash" in any meaningful sense
12:31 < andytoshi> it can be any type that has a couple of standard capabilities (Display, FromStr, etc) and which has a mapping from keys (but not a mapping *to* keys necessarily)
12:33 < andytoshi> i've considered adding another trait to characterize "reversible hashes" where you can actually map from a hash to a key, for use-cases like this, but (a) we haven't needed it yet; (b) i think that'd be genuinely confusing
12:33 < andytoshi> and (c) rust's lack of specialization means that it'd be a lot less useful than you'd hope
12:40 < darosior> Ok, pushed. Was quite simpler
12:51 < andytoshi> awesome, thanks
12:51 < andytoshi> i saw you addeda fuzztest as well - did you get that to pass?
12:52 < darosior> Yep     
12:52 < darosior> Squashed the fix, don't know if you prefer fixups instead for reviews ?
12:56 < sanket1729> w.r.t to hack to Hash returning identity.
12:57 < sanket1729> Why not change it properly to a better variable and do the same for bitcoin::PublicKey?
12:57 < sanket1729> Discussing things out of things of the current PR
12:58 < sanket1729> Somehow I think we are doing things in a bit contrived way. 
13:01 < sanket1729> Yup, the more I think about this. I think we should also do this for bitcoin::PublicKey
13:01 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Quit: jonatack]     
13:09 < sanket1729> It seems that that generic parameter git in better here instead of associated type?
13:10 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined ##miniscript     
13:29 < sanket1729> nevermind, it does not make sense
13:36 < sanket1729> I still think what darosior did previously(though an invasive change) might be the correct way to do it. 
13:37 < darosior> sanket1729: saved my branch "just in case" ;)
13:38 < sanket1729> andytoshi: I have updated the heightlock PR so that all the logic in one place. Should be much easier to review now
21:16 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Read error: Connection reset by peer]     
21:16 -!- achow101_ [~achow101@unaffiliated/achow101] has joined ##miniscript