--- Log opened Wed Dec 30 00:00:02 2020
00:17 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]
00:18 -!- shesek [~shesek@164.90.217.137] has joined ##miniscript
00:18 -!- shesek [~shesek@164.90.217.137] has quit [Changing host]
00:18 -!- shesek [~shesek@unaffiliated/shesek] has joined ##miniscript
00:58 -!- willcl_ark [~quassel@cpc123780-trow7-2-0-cust177.18-1.cable.virginm.net] has quit [Quit: Quit]
00:59 -!- willcl_ark [~quassel@cpc123780-trow7-2-0-cust177.18-1.cable.virginm.net] has joined ##miniscript
06:09 -!- jonatack [~jon@213.152.161.211] has quit [Ping timeout: 260 seconds]
06:10 -!- jonatack [~jon@88.124.242.136] has joined ##miniscript
06:15 -!- jonatack [~jon@88.124.242.136] has quit [Ping timeout: 256 seconds]
06:15 -!- jonatack [~jon@104.254.90.235] has joined ##miniscript
08:50 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Quit: Leaving]
08:52 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined ##miniscript
08:52 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 240 seconds]
09:01 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Ping timeout: 240 seconds]
09:32 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined ##miniscript
09:40 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined ##miniscript
12:48 < andytoshi> why is hardened derivation not supported?
12:48 < sipa> in?
12:48 < andytoshi> err, in rust-miniscript for wildcard descriptors
12:48 < andytoshi> we specifically disallow *' right now with the error "currently not supported"
12:48 < andytoshi> and i wonder what was difficult about this
12:49 < sipa> ah
12:49 < andytoshi> i think i remember some complicated API reason, which is unfortunate because i need these to use my icboc wallet..
12:51 < andytoshi> oh it may just be that we have a boolean right now to store wildcardness, and we'd need a three-valued thing instead
12:57 < andytoshi> also we fail to parse *h at all
14:38 < sanket1729> andytoshi: I think someone pointed out that we didn't want to implement MiniscriptKey bounds like Ord on privatekeys etc. 
14:45 < sanket1729> I don't really know how to evaluate such side channel attacks. Worst case, we can impl Ord with everything being equal
14:46 < sipa> a descriptor with private keys is just syntactic sugar for the equivalent with public keys, while also relaying the relevant private keys
14:46 < sipa> so i'd say sorting/equality testing should be equivalent to just using the pubkeys?
14:48 < andytoshi> right, i'm not sure what this would have to do with hardened derivations
14:48 < sanket1729> using 0 for * in wildcards
14:48 < sanket1729> ?
14:48 < sipa> ?
14:48 < sipa> what does that have to do with it?
14:49 < sanket1729> How to derive a public key for comparison with when don't the derivation path?
14:49 < sipa> why would you need to derive anything?
14:49 < andytoshi> i don't understand what you're asking, and i'm most of the way through implementing *h..
14:50 < sanket1729> What is your impl for Ord?
14:50 < andytoshi> i haven't touched that, i assume i won't have to
14:50 < andytoshi> but i guess * would sort before *h
14:50 < andytoshi> if i had to think about that explicityl
14:51 < sanket1729> one sec. reviewing bip32. Maybe what I am saying makes no sense. 
14:52 < sipa> sorting of descriptor keys should just sorting (xpub, derivation path, flag at the end) or so
14:52 < sipa> where the xpub internally consists of a pubkey and a chaincode, or whatever
14:52 < sipa> you shouldn't need to do any derivation to compare descriptors
14:52 < sipa> (or subexpressions thereof)
14:55 < andytoshi> ah ok, so i think the API reason we didn't do this is that it would make pubkey derivation fallible
14:56 < andytoshi> if you provided a hardned childnumfor *, or a normal one for *h
14:56 < andytoshi> although our existing code panics if you provide a hardened key for * ..... and does nothing if you provide a normal key without a wildcard ... neither of which are ideal
14:56 < sipa> what is a "hardened childnum" ?
14:57 < andytoshi> one that's encoded with the high bit set to 1
14:57 < sipa> i think you're confused :)
14:58 < andytoshi> and which, when passed to the bip32 derivation functions, doe sa hardened derivation
14:58 < sipa> if you have xpubX/1/*h, then its first derived is xpubX/1/0h, the next one is xpubX/1/1h, ...
14:58 < andytoshi> yes
14:58 < sipa> where "h" just means "add 2^31"
14:58 < sipa> how could things fail?
14:58 < andytoshi> the rust-bitcoin API is more strongly typed than that
14:58 < sipa> ok, i don't see how that's related
14:58 < andytoshi> if you provide a ChildNumber::Hardened { anything }
14:59 < sipa> for what?
14:59 < andytoshi> for the number that * is replaced by
14:59 < sipa> that's not how descriptors work
15:00 < sipa> they expand to a list of scripts, not something where the caller needs to know if hardened or unhardened derivation will be used
15:00 < sipa> you pass a descriptor and an integer, and you get a scriptPubKey
15:00 < andytoshi> ok, so suppose that you pass an integer greater than 2^31
15:00 < sipa> that'll always fail
15:01 < sipa> you can have a descriptor sh(multi(xpubA/*,xpubB/*h)) if you want
15:01 < sipa> which expands to sh(multi(xpubA/0, xpubB/0h)), sh(multi(xpubA/1, xpubB/1h)), ...
15:01 < andytoshi> ahh good catch, in the API that i'm writing that'd barf
15:01 < andytoshi> yep i gotcha
15:02 < andytoshi> ok, cool, so the API actually does need to take integers, not ChildNums
15:02 < sipa> ah, cool
15:02 < andytoshi> and internally it would convert to a ChildNUm, following the wildcard
15:02 < sipa> right
15:02 < andytoshi> so, no falirue except if the user provides a number > 2^31, which is easy enough for the caller to check so i'll just leave that as a panic..
15:03 < sipa> you could have a descriptor with no xpubs, which should probably fail for any index != 0
15:04 < sipa> or rather, with no /* in its key expressions
15:04 < andytoshi> yeah, what we currently do is just always return the unmodified descriptor
15:04 < andytoshi> i think it _should_ fail, but the resulting API is more annoying to use
15:05 < sipa> i think in bitcoin core descriptors have a boolean property "ranged", but other than that the index is just ignored for unranged descriptors
15:05 < sipa> this lets callers know that there is no point evaluating at index>0
15:06 < andytoshi> ok, cool, that's also what we do
15:06 < andytoshi> we call ours "is_wildcard" but we should maybe rename that to match core
15:08 < sipa> a better interface (which i just made up on the spot...) is exposing a max_index for descriptors, which is just the maximum of all the maxima of the key expressions
15:08 < sipa> but if we ever want to have combinators for concatenating or interleaving key expressions, that'd let things keep working
15:09 < andytoshi> that's not a bad idea...in Core can you set the maximum explicitly?
15:09 < andytoshi> i think in our descriptors the max is always 2^31
15:09 < sipa> (one reason why you'd want that is for representing a wallet that just consists of 1000 pregenerated keys or so)
15:09 < sipa> so you'd do sh(wpkh([key1,key2,key3,...])) or so
15:09 < sipa> as a descriptor
15:11 < sipa> i think currently the range used depends on the caller code; for some cases (scantxoutset e.g.) the range is just provided by the RPC user, for others (the wallet, since 0.21, if you use descriptor wallets) it'd derived automatically based on gap limit
15:13 < andytoshi> ok, makes sense ... so it might cause confusion if we tried to make that a property of the descriptor
15:36 < andytoshi> ah, ok, now i see the actual API issue ... we currently have an infallible "convertible to EC pubkey" trait on our wallet pubkeys
15:36 < andytoshi> which we should not have
15:46 < andytoshi> sanket1729: so....we can make ToPublicKey fallible, which would suck because it would make basically every single descriptor method fallible
15:46 < andytoshi> or we could make DescriptorPublicKey no longer implement ToPublicKey
15:47 < andytoshi> but given that this was the sole reason for our elaborate ToPkCtx infrastructure (well, that and pegins, which we've discovered also don't work..)
15:47 < andytoshi> maybe we should drop ToPkCtx :P
16:03 < andytoshi> sanket1729: hmm, super frustrating that we can't get the translate_pk method into the descriptor trait
16:03 < andytoshi> this is actually a higher-kinded-type thing, i don't think we can sensibly hack around ti
16:04 < andytoshi> other than by just porting the whole lib to haskell
16:04  * sipa suggests: using an untyped language
16:05 < andytoshi> hehehe
16:05 < sipa> everything will just magically work!
16:05 < sipa> (until it doesn't)
16:07 < andytoshi> hmm, i think we may actually be able to do this by erasing a bit of type information ... let me play with it a bit
16:09 < andytoshi> rust lets you have functions like "fn convert_pk(self, convertfn) -> impl DescriptorTrait<NewPkType>" where the return type "impl DescriptorTrait" indicates that the function is allowed to return whatever type it wants, provided it implements that trait, and then the callee isn't allowed to make any assumptions about the return type, except that it implements the trait
16:09 < andytoshi> sorta a narrowly-scoped form of duck typing
16:10 < sipa> quack
16:25 < andytoshi> oh actually i see what you've done sanket1729 with the PkTranslate trait ... that's probably more ergonomic than the thing i was thinking about
16:25 < andytoshi> i would like to see if we can get rid of the line noise though related to the pkhash conversion function
16:25 < sanket1729> You suggested :P 
16:25 < andytoshi> lol oh :P
16:25 < andytoshi> that's right, i remember now
16:35 < andytoshi> man this PR is enormous
16:38 < andytoshi> ok, but ACK it once my local CI scripts finish
16:38 < andytoshi> i need to rewrite these to use more cores..
17:32 < sanket1729> There are couple of changes that I need to addres
--- Log closed Thu Dec 31 00:00:03 2020