--- Log opened Wed Apr 13 00:00:53 2022 02:15 -!- meshcollider [meshcollid@meshcollider.jujube.ircnow.org] has quit [Ping timeout: 240 seconds] 02:55 -!- afilini [~afilini@2001:bc8:1828:245::2] has joined ##miniscript 02:55 < afilini> has anybody tried writing a fuzzing "framework" for miniscript? 02:57 < afilini> i think it would be non-trivial, but in theory you could simulate the execution in btcdeb and see if the fuzzer can come up with a script_sig/witness that satisfy the script 02:59 < darosior> afilini: sipa and i have been trying to come up with different approaches to fuzzing Miniscript for the past months. The (presumably final) result of all iterations is https://github.com/sipa/miniscript/blob/202202_decodefuzz/bitcoin/test/fuzz/miniscript.cpp which features serialization fuzzing, fuzzing based on a defined encoding, and "smart" 02:59 < darosior> fuzzing trying to generate a valid node at every iteration based on some rules we came up with 03:00 < darosior> See the repo and the logs of this channel (https://gnusha.org/miniscript/) for discussions around this 03:04 < afilini> that's awesome, i wasn't aware it existed 06:11 -!- meshcollider [meshcollid@meshcollider.jujube.ircnow.org] has joined ##miniscript 08:03 < afilini> i'm updating bdk to the new miniscript rc, i'm not sure what i'm supposed to do here: what am i supposed to do in the implementation of `ToPublicKey::to_public_key()` is self is a SinglePubKey::XOnly? 08:04 < afilini> if self is* 08:05 < afilini> i guess i should just panic since i can't return a result. is there a check during parsing that prevents x-only keys from making it into non-tr descriptors? 10:36 < sanket1729> afilini: It should be 0x02[x-only-key] 10:37 <@sipa> sanket1729: 64-hex arguments to tr() and pk() inside tr are valid 10:37 < sanket1729> Yes, they are 10:37 <@sipa> oh, ok; i may misunderstand the context then 10:38 <@sipa> (carry on) 10:38 < sanket1729> I think afilini's question was about obtaining a public-key given a x-only key 10:39 < sanket1729> afilini: Why are you implementing ToPublicKey? Can you share your code 10:41 < sanket1729> afilini: It should not be possible to use x-only keys in non-tr descriptors. 10:55 < sanket1729> Actually, this is a copy-paste bug on my side. 10:55 < sanket1729> andytoshi, afilini: https://github.com/rust-bitcoin/rust-miniscript/pull/344. One word diff, should be easy to review. 11:04 < afilini> I'm essentially implementing it on DescriptorPublicKey 11:05 < afilini> Which means that I have to handle the case where the DescriptorPublicKey is a single key 11:06 < afilini> This is what it looks like pre-taproot: https://github.com/bitcoindevkit/bdk/blob/master/src/descriptor/derived.rs#L136-L152 11:07 < afilini> DerivedDescriptorKey is a wrapper over DescriptorPublicKey which ensures that all extended keys have a complete derivation path, basically that they don't contain wildcards 11:07 < afilini> Which means that I can always perform the conversion to a single raw PublicKey 11:26 < sanket1729> afilini: see https://github.com/rust-bitcoin/rust-miniscript/blob/d8cc633b5b726e7ae595031ba04dcc1c1c2d6fda/src/lib.rs#L252 11:28 < afilini> oh okay, yeah, i could do that 11:28 < afilini> i guess my question was more like: how bad it is if we accidentally accept an x-only key in a non-tr descriptor? is it better to panic instead? 11:28 < sanket1729> afilini: We can do DerivedDescriptorPublicKey type in rust-miniscript next release 11:29 < sanket1729> Depends on your application 11:30 < sanket1729> You should error if possible 11:30 < sanket1729> 64 byte keys are not allowed in non tr descriptors 11:31 < afilini> if you find my code useful i could try upstreaming it. it's not that much code, it's the definition of the struct (plus the required traits) and I think I have a extra trait called `AsDerived` which takes a derivation index and replaces all the wildcards in the keys with that index in a descriptor (basically translates from `Descriptor` to `Descriptor` 11:32 < afilini> actually if I upstream it i don't even need the `AsDerived` trait, that was a workaround to implement a method on a struct from another crate. it could be directly a method on `Descriptor` 11:33 < sanket1729> Yeah, please I think this will be useful for our APIs too. But it won't be probably be ready for 7.0.0 14:43 -!- shesek [~shesek@user/shesek] has joined ##miniscript 15:16 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection] 15:17 -!- shesek [~shesek@user/shesek] has joined ##miniscript 15:41 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection] 15:41 -!- shesek [~shesek@user/shesek] has joined ##miniscript 15:57 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection] 15:57 -!- shesek [~shesek@user/shesek] has joined ##miniscript 16:16 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection] 16:16 -!- shesek [~shesek@user/shesek] has joined ##miniscript 16:26 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection] 16:27 -!- shesek [~shesek@user/shesek] has joined ##miniscript 16:34 -!- shesek_ [~shesek@user/shesek] has joined ##miniscript 16:36 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection] 17:08 -!- shesek_ [~shesek@user/shesek] has quit [Remote host closed the connection] 17:09 -!- shesek_ [~shesek@user/shesek] has joined ##miniscript 17:12 -!- shesek__ [~shesek@user/shesek] has joined ##miniscript 17:13 -!- shesek_ [~shesek@user/shesek] has quit [Read error: Connection reset by peer] 17:25 -!- shesek__ [~shesek@user/shesek] has quit [Remote host closed the connection] 17:25 -!- shesek__ [~shesek@user/shesek] has joined ##miniscript 17:37 -!- shesek__ [~shesek@user/shesek] has quit [Remote host closed the connection] 17:38 -!- shesek__ [~shesek@user/shesek] has joined ##miniscript 17:42 -!- shesek__ [~shesek@user/shesek] has quit [Remote host closed the connection] --- Log closed Thu Apr 14 00:00:56 2022