--- Log opened Tue Sep 13 00:00:18 2022
01:42 -!- devrandom [~devrandom@2001:470:69fc:105::d4d] has quit [Quit: Bridge terminating on SIGTERM]
01:42 -!- ksedgwic [~ksedgwicm@2001:470:69fc:105::ce1] has quit [Quit: Bridge terminating on SIGTERM]
01:42 -!- sipa [~sipa@user/sipa] has quit [Quit: Bridge terminating on SIGTERM]
01:46 -!- ksedgwic [~ksedgwicm@2001:470:69fc:105::ce1] has joined ##miniscript
02:01 -!- sipa [~sipa@user/sipa] has joined ##miniscript
02:01 -!- mode/##miniscript [+o sipa] by ChanServ
02:01 -!- devrandom [~devrandom@2001:470:69fc:105::d4d] has joined ##miniscript
02:21 < michaelfolkson> What's the point of fuzzing the Miniscript code? To try to generate a script that the wallet can't handle? The Miniscript implementation was effectively fuzzed to the extreme when it was first designed right?
02:21 < michaelfolkson> I guess it can't hurt to keep fuzzing it especially as there have been a few small changes since
02:32 < darosior> The implementation changed a lot. Fuzzing allows to test some invariants hold (eg "we won't crash when parsing", or "if a Miniscript has property X, then operation Y will always succeed") for a large number of inputs in a more efficient manner than by randomly generating them. Fuzzing helped us uncover many bugs, and it helps to not re-introduce
02:32 < darosior> some when modifying the code.
02:44 < michaelfolkson> Ok interesting, thanks. I'm surprised by "Changed a lot". The fragments, wrappers etc haven't changed much since the start. Didn't appreciate a lot has changed behind them
02:51 < darosior> The implementation did change a lot in 2 years. Since 027b422495a8ee3ea3fa7787150389bb65d1b9de, committed in September 2020, that's a +3600 -1500 diff: https://github.com/sipa/miniscript/compare/027b422495a8ee3ea3fa7787150389bb65d1b9de..master (Many of the additions are tests but it's still "a lot" compared to the size of the codebase).
02:51 < darosior> The language did change a little bit but not that much. Anyways fuzzing is for the implementation of the language, and can help for testing language completeness (make sure you can always spend under all the conditions described by the semantic). But it can't help for language soundness (make sure you can't bypass those conditions), as with the
02:51 < darosior> recent bug with the 'd:' fragment.
02:59 < afilini> It should be possible to fuzz those as well though, right? You could manually craft a set of descriptors so that all of the language constructs are covered, then let a fuzzer generate random witnesses and use libbitcoinconsensus to verify them
02:59 < afilini> I mean fuzzing to ensure language soundness 
03:50 < michaelfolkson> Soundness being defined how? :) The MINIMALIF, d: fragment bug darosior referred to is soundness I guess though you wouldn't expect normal fuzzing to catch it
03:51 < michaelfolkson> Needs very intelligent fuzzing to explore the pre Taproot to post Taproot transition
04:21 < afilini> Maybe I'm just too optimistic, but I think it could have worked 
04:23 < afilini> Say you have a descriptor with like thresh(5), in theory a fuzzer should notice that there's a branch in the consensus code taken only if a value is equal to 5 (the OP_EQUAL). Walking backwards it could figure out to just push 5 on the stack rather than a random number to explore that branch as well
04:28 < afilini> If I were to do it I would probably change bitcoinconsenus to always consider signatures invalid, to make sure the fuzzer doesn't get lost in all the crypto code trying to find valid signatures (and also hash/preimages). Other than that the interpreter is probably pretty straightforward, I think a fuzzer would be able to build witnesses to directly affect the code paths taken in the code 
05:53 <@sipa> Our fuzzer does construct witnesses that get tested by consensus code.
05:53 <@sipa> (by stubbing out the signature validation)
--- Log closed Wed Sep 14 00:00:19 2022