--- Log opened Tue Feb 15 00:00:59 2022
01:18 < darosior> Regarding address descriptors in rust-miniscript, i think they are useful. See https://github.com/rust-bitcoin/rust-miniscript/issues/294 for an instance, but i'm sure there are others.
01:18 < darosior> Regarding "it does seem like we need a rawpkh to represent pkh's inside miniscript" -> there is always the possibility to treat a pkh() with a 20-bytes argument as a rawpkh() implicitly. But i slightly prefer being explicit and introducing rawpkh(), at the expense of a small redundancy with addr() when used at top-level
02:33 -!- midnight [~midnight@user/midnight] has quit [Ping timeout: 268 seconds]
02:34 -!- midnight [~midnight@user/midnight] has joined ##miniscript
03:13 < sanket1729> andytoshi: https://gist.github.com/sanket1729/b1ed8ed776c7ac798d5e33e40f5d996d
03:14 < sanket1729> darosior: yup, we can introduce addr, but that might be post taproot release :(
03:14 < darosior> Sure, no rush
03:15 < sanket1729> rawtr slightly confuses me, it is sometimes a raw descriptor, but sometimes a full descriptor 
03:15 < sanket1729> Not sure how to classify it, or if we can call it raw
03:17 < sanket1729> I am assuming raw means there is some information about the creation the descriptor hidden. rawpkh means pk is hidden, rawnode means node is hidden. 
03:18 < sanket1729> But sometimes rawtr might just output key without any BIP341 tweaking or any script path. Or it can be something complex that we don't know
03:18 < sanket1729> So, sometimes is solvable and sometimes not
05:44 < andytoshi> sanket1729: well, it's always solvable by key-spend
05:45 < andytoshi> and if i understand right, it's never solvable by script-spend
05:46 <@sipa> @sanket1729 I think the concern of availability is mostly orthogonal. It may be useful to define a way to signal that in descriptors, but I guess it'd be some marker before/around the relevant keys (e.g. + or -).
05:48 <@sipa> @sanket1729 also, yes, just pkh with 40 hex characters would work as a rawpkh syntax, but I think it'd be confusing (very close to the 66 hex characters pubkey one, doesn't convey this is really partial information).
05:52 <@sipa> @sanket1729 Hmm, it's true that rawtr is not really the same as others, especially because it takes a key expression (e.g. a bip32 path), not just hex.
14:43 < sanket1729> sipa: I tend to like the explicitness of raw* 
14:44 <@sipa> Yeah, me too.
14:47 < sanket1729> I think we might need to have some general solution for coin-selection based on availability because we will face the same problem with estimating tr descriptor key spend. What was the conclusion last time?
14:48 <@sipa> It's mostly a logistical issue... where is that information?
14:49 <@sipa> Perhaps in some circumstances you know that in a particular wallet, when using a particular descriptor, certain keys will always/never be available.
14:49 < sanket1729> I thought we want some uniform way/format to convey that information. 
14:49 <@sipa> But it may also be something that is only known at spending time itself.
14:50 <@sipa> In which case it'd be very inconvenient to have to "plug" that into an existing descriptor. Users shouldn't even be seeing these things.
14:51 <@sipa> Maybe a possibility is having things like "labels" on descriptor keys/hashes, and then have an additional input to estimating functions which is information about availability based on keys' labels.
14:53 <@sipa> Like you can label your 3 keys in a 2-of-3 multisig "cold", "phone", "green" or so, and then you could tell the estimator/... which of these are available, based on name.
14:53 < sanket1729> I see, this makes intuitive sense. 
14:54 < sanket1729> But do the labels need to be a part of descriptor spec? Why not provide the mapping directly from keys?
14:54 <@sipa> That doesn't preclude being able to do the same thing in descriptors directly, or even having this approach (of labels + label-specific availability) be something that results in a merged descriptor with the availability info in it.
14:55 <@sipa> What is "mapping directly from keys"?
14:55 < sanket1729> > additional input to estimating functions which is information about availability based on keys' label
14:55 <@sipa> Well I'm imagining the user can select which keys are available, but they shouldn't need to actually see a descriptor or key for that.
14:56 <@sipa> Whether that's done through the descriptors themselves, or some layer on top... unsure.
15:05 < sanket1729> I am liking the idea of (optional) labels for all constraints(keys, hashes, timelocks) in descriptors itself. Is it possible to do in backwards compatible way for Key expressions?
15:15 <@sipa> no
15:15 <@sipa> descriptors are generally not backward compatible
16:44 <@sipa> @darosior Sorry for not continuing work on the fuzz tests yet; will get to it soon.
22:08 -!- midnight [~midnight@user/midnight] has quit [Remote host closed the connection]
22:09 -!- midnight [~midnight@user/midnight] has joined ##miniscript
22:10 -!- meshcollider [meshcollid@jujube.ircnow.org] has quit [Ping timeout: 240 seconds]
22:19 -!- Bikram [~Bikram@103.220.88.193] has joined ##miniscript
22:19 -!- meshcollider [meshcollid@meshcollider.jujube.ircnow.org] has joined ##miniscript
22:43 -!- Bikram [~Bikram@103.220.88.193] has quit [Quit: Client closed]
--- Log closed Wed Feb 16 00:00:00 2022