--- Log opened Fri Jul 23 00:00:15 2021
12:01 -!- sanket_cell [~sanket172@ec2-100-24-255-95.compute-1.amazonaws.com] has quit [Ping timeout: 252 seconds]
12:01 -!- sanket_cell_ [~sanket172@ec2-100-24-255-95.compute-1.amazonaws.com] has joined ##miniscript
12:01 < sanket1729_> andytoshi, darosior: In rust-miniscript, we don't part things like `or_i(child1, 0)` or `or_i(0, child2)` because we enforce that users should use `l` (likely) or `u`(unlikely) wrappers
12:02 < sanket1729_> I don't think we should be disallowing reading those from strings. But this will break a lot of our roundtrip tests :( 
12:04 < sanket1729_> Or maybe provide additional methods to parse those. 
12:06 < sanket1729_> Atleast in the spec, we don't have any rules that  syntactic sugar for t, l, and u must be used when applicable
13:22 < andytoshi> we should have such rules
13:23 < andytoshi> though i guess it wouldn't be hard for us to just add yet another special case to the round-trip tests
14:06 < sanket1729_> The miniscript String -> Node round trip boat sailed when we added new aliases pk() -> c:pk_k() and pkh() -> c:pk_h() .
14:08 < sanket1729_> It seemed like a good property to have. But :( 
14:18 < sanket1729_> I am trying to port test vectors which Dmitry generated from alloy spec and it has such vectors which rust-miniscript is not accepting. 
14:27 < andytoshi> i thought we also forbade c:pk_k and c:pk_h
14:27 <@sipa> perhaps it's not unreasonable that more such shortcuts get added in the future?
14:28 <@sipa> if that's the case, maybe it's not a desirable property that only the shortened form is accepted
14:35 < sanket1729_> agreed. I think we should accept all forms. 
14:36 < sanket1729_> The one problem we face is deserialize and serialize a miniscript descriptor, the checksum can change
14:36 < sanket1729_> which is confusing
14:41 <@sipa> the checksum is just for transmission errors
14:41 < sanket1729_> ah, right
14:42 < andytoshi> i forget where we landed the last time somebody asked for a "descriptor ID"
14:44 < sanket1729_> Do descriptors with ' and h have same ID?
14:44 < sanket1729_> or different ones?
14:45 < sanket1729_> Maybe ID is just the identity function, the descriptor string itself
14:46 <@sipa> i think bitcoin core just uses the descriptor string or hash of it as ID
14:46 <@sipa> achow101: ?
14:47 < achow101> Core uses the sha256 of whatever ToString() outputs
14:48 < sanket1729_> Interesting, so the while parsing core needs to store whether the descriptor string used h or ' ? 
14:49 < achow101> ToString normalizes to '
14:50 < sanket1729_> Can the new descriptor BIPs recommend using ' over h ?
14:50 < sanket1729_> Or are recommendations outside the BIP specification?
14:51 < achow101> the bip recommends h over '
14:52 < achow101> this id is internal to core and could be different
14:52 < achow101> it's not actually part of the descriptor module
14:52 <@sipa> achow101: is the ToString() form also what is stored in the wallet?
14:52 < achow101> yes
14:53 <@sipa> ok, so we could change the descriptor code to actually remember whether h or ' was used, and make it roundtrip
14:53 <@sipa> and that wouldn't break anything
14:54 < achow101> yeah
15:21 < andytoshi> it would be nice if there were an actual official ID
15:21 < andytoshi> and if this did not depend on serialization
15:21 < andytoshi> but i think we had this conversation six months ago?
15:31 <@sipa> i vaguely remember something like that
15:31 <@sipa> like using a particular derived key or so?
15:32 <@sipa> (which wouldn't actually uniquely identify the descriptor)
15:44 < andytoshi> yeah i think the conversation might've fizzled out as we couldn't decide how the key would be encoded into the identifier
21:22 -!- dr-orlovsky [~dr-orlovs@31.14.40.19] has joined ##miniscript
--- Log closed Sat Jul 24 00:00:16 2021