--- Log opened Mon Dec 21 00:00:54 2020
01:30 -!- shesek [~shesek@164.90.217.137] has joined ##miniscript
01:30 -!- shesek [~shesek@164.90.217.137] has quit [Changing host]
01:30 -!- shesek [~shesek@unaffiliated/shesek] has joined ##miniscript
01:54 -!- jeremyrubin [~jr@c-24-4-205-116.hsd1.ca.comcast.net] has quit [Ping timeout: 260 seconds]
07:20 -!- roconnor [~roconnor@host-45-78-199-13.dyn.295.ca] has quit [Quit: Konversation terminated!]
07:20 -!- roconnor [~roconnor@host-45-78-199-13.dyn.295.ca] has joined ##miniscript
09:45 -!- roconnor [~roconnor@host-45-78-199-13.dyn.295.ca] has quit [Ping timeout: 264 seconds]
09:50 -!- jeremyrubin [~jr@2601:645:c200:14:d16a:4949:3622:4cc0] has joined ##miniscript
11:35 < sanket1729> andytoshi: For key tweaking feature our current ToPkCtx also needs a method to get the underlying secp ctx
11:35 < andytoshi> the secp ctx should be part of the ToPkCtx
11:35 < sanket1729> It is
11:35 < sanket1729> but we need a method to get access to it
11:35 < sanket1729> as a trait method
11:36 < andytoshi> i think you can only implement tweaking of ToPkCtx is a concrete type
11:36 < andytoshi> most ToPkCtxes won't have a secp context in them
11:36 < sanket1729> Then, we need to store the tweak value inside the ToPkCtx
11:36 < sanket1729> sorry
11:36 < sanket1729> inside Pk
11:37 < andytoshi> hmm are you able to paste some code
11:37 < sanket1729> sure
11:37 < andytoshi> in my head ToPkCtx would be a (context, tweak) pair
11:38 < andytoshi> and with that specific ToPkCtx, you'd get a tweaked address out
11:38 < sanket1729> ah, I did not provide context for the discussion
11:38 < sanket1729> for pegin descriptors
11:38 < sanket1729> The tweak is same for all the values. 
11:38 < andytoshi> right ... so a pegin descriptor has a miniscript::Descriptor<FunctionaryKey> in it
11:38 < andytoshi> and we can impl ToPublicKey on FunctionaryKey with (context, tweak) as ToPkCtx
11:39 < andytoshi> and also implement it with NullCtx (or whatever we called that)
11:39 < andytoshi> and the former would give a tweaked key, and the latter would give an untweaked key
11:39 < sanket1729> This is true, but is awkward API wise. 
11:40 < sanket1729> because we know the tweak at the descriptor creation time
11:40 < andytoshi> right
11:40 < sanket1729> that information is saved in descriptor. And not something which we provide while converting to script
11:40 < andytoshi> right
11:40 < andytoshi> so the script conversion method (.encode()) i guess
11:40 < sanket1729> So, it seems odd to put that info inside ToPkCtx. 
11:41 < andytoshi> needs to
11:41 < andytoshi> 1. compute the script for the user descriptor, to get the tweak
11:41 < andytoshi> 2. put that tweak into a (ctx, tweak) pair
11:41 < andytoshi> 3. call .encode on the functionary descriptor
11:41 < andytoshi> with that pair
11:42 < andytoshi> so the context the _user_ provides is just the secp context
11:42 < andytoshi> and internally the descriptor would figure out the tweak (or have it cached or whatever)
11:42 < sanket1729> But that does not fit the trait method specifications we have. It would be separate method
11:42 < sanket1729> DescriptorTrait interface i mean
11:44 < sanket1729> https://github.com/rust-bitcoin/rust-miniscript/blob/f0d38d602d9c4723ab1c47a0a8542da08505da89/src/descriptor/mod.rs#L98
11:47 < andytoshi> i don't understand
11:47 < andytoshi> why can't you implemnet the method i just described with that API
11:48 < sanket1729> Note, that tweak is a part of selfd
11:48 < sanket1729> tweak computation logic
11:48 < andytoshi> yeah
11:48 < andytoshi> so `address` on PeginDescriptor would figure out its tweak, then pass to `address` on the functionary descriptor
11:49 < andytoshi> giving a (secpctx, tweak) as the ToPkCtx
11:52 < sanket1729> okay, that does make sense. (topkctx, tweak) as ToPkCtx. 
11:52 < sanket1729> In my head, I had topkctx as being some instance of ToPkCtx which we can't substitute for anything else. 
11:53 < sanket1729> But ToPkCtx can be anything, and does not have to be the same type. 
11:53 < andytoshi> yep
11:53 < sanket1729> Nevermind, I was unnecessarily trying out more complicated things. What you say is super simple. 
11:53 < andytoshi> :)
13:16 < sanket1729> andytoshi: If this is what you meant for me to try, it is not working...
13:16 < sanket1729> https://gist.github.com/sanket1729/2e1bf9f2a1bae326f75ebcf983a369ce
13:19 < andytoshi> what is the key type on the federation descriptor
13:20 < andytoshi> sounds like it's the Pk that the pegin desciptor is parameterized over?
13:20 < sanket1729> I am trying to keep everything geneirc
13:20 < andytoshi> you can't
13:20 < sanket1729> Do you want to concretize Functoinary Key
13:20 < andytoshi> or you can add a new FunctionaryKey trait
13:20 < andytoshi> yes, that was my intention
13:20 < andytoshi> the types of functionary keys are set by the consensus rules of elements
13:21 < andytoshi> it's up to you whether you want to make FunctionaryKey a type or a trait, i suppose .. but you can't use a Pk:ToPublicKey
13:21 < andytoshi> or MiniscriptKey, or whatever 
13:22 < sanket1729> I wanted to reuse the parsing code which is for MiniscriptKey
13:22 < sanket1729> String parsing
13:22 < andytoshi> you could use MiniscriptKey+FunctionaryKey
13:23 < andytoshi> but you need another bound (or a concrete type) to be able to tweak the keys
13:23 < sanket1729> Do trait implementation allow stricter bounds?
13:23 < andytoshi> i don't understand the question
13:23 < andytoshi> you need a method that can tweak the keys. you can add that to a concrete type or define a trait for it
13:24 < sanket1729> descriptorTrait is for Pk: MiniscriptKey, Can I implement something a struct with Pk: MiniscriptKey + FunctionaryKey
13:25 < sanket1729> Anyways, with a concrete type, I can figure out rest of the stuff
13:26 < andytoshi> oh right, i forgot DescriptorTrait is parameterized over Pk
13:26 < andytoshi> so, you're already gonna have trouble, even without additional bounds, because the functionary keys are a different type from the user keys
13:26 < andytoshi> so you need two different parameters (if you really wanna be generic) on the pegin descriptor
13:27 < sanket1729> perhaps three, because the emergency keys are a different type :P
13:27 < andytoshi> well, the emergency keys would be a different variant on a FunctionaryKey enum
13:27 < andytoshi> they can't actually be a different type
13:27 < andytoshi> because they occur together in the same descriptor as functionary keys
13:29 < sanket1729> one more point for discussion, does it really make sense to have functionary keys in the descriptor? If we expect the wallet parsing these to construct these wierd OP_DEPTH scripts, can we not expect to have hard-coded keys?
13:30 < andytoshi> hardcoded to what?
13:31 < sanket1729> the actual keys?
13:31 < andytoshi> what actual keys? like on the production liquid network
13:31 < sanket1729> I suppose they are known publicly
13:31 < andytoshi> ?
13:31 < sanket1729> Oh, we are writing something that is not liquid specific
13:31 < andytoshi> correct
13:31 < andytoshi> welll, the legacy descriptor stuff is liquid specific
13:31 < andytoshi> but we still have test networks for liquid
13:31 < andytoshi> so we can't fix the keys
13:32 < andytoshi> but you can certainly fix the key _type_ to just be some tweakable/untweakable enum
13:34 < sanket1729> cool. I think I will write the concrete type one instead of generic one. The only drawback is that tests will have massive things in them
13:34 < sanket1729> Maybe, I will have a trait for this. We also lose the translation feature. 
13:35 < andytoshi> heh if only we had constexprs
13:35 < andytoshi> you colud just hradcode the functionary keys as constants
13:36 < andytoshi> wdym "we also lose the translation feature"
13:36 < sanket1729> write something as legacy_pegin("a", "b") and translate "a", "b" to concrete keys
13:37 < andytoshi> are "a" and "b" keys here? user keys or functionary keys?
13:37 < andytoshi> i don't see why you can't translate user keys
13:37 < sanket1729> functionary keys
13:37 < sanket1729> you can translate user keys
13:38 < andytoshi> ah ... i mean doing that was always going to be difficult, because the existing translation methods assume you have only one key type in your descriptor
13:40 < sanket1729> yeah, we don't want to create more custom methods which take in like 4 paramters which are functions. 
13:40 < andytoshi> lol yeah
14:08 -!- Ed0 [~edouard@137.ip-193-70-113.eu] has quit [Ping timeout: 240 seconds]
14:08 -!- Ed0 [~edouard@2001:41d0:401:3100::4897] has joined ##miniscript
23:17 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]
--- Log closed Tue Dec 22 00:00:53 2020