<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 11, 2019 at 10:29 PM Gregory Maxwell <<a href="mailto:gmaxwell@gmail.com">gmaxwell@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The result is a collection of 7371 inputs extracted from a few billion<br>
attempts that collectively hit the as broad a coverage footprint as I<br>
observed in this test run:<br>
<br>
<a href="https://people.xiph.org/~greg/simplicityC_tests.tar.xz" rel="noreferrer" target="_blank">https://people.xiph.org/~greg/simplicityC_tests.tar.xz</a> (78kb, expands to 7.3mb)<br>
<br>
The files are named based on the result of the execution, e.g.<br>
successes vs various failures and roughly where they failed.<br>
<br>
Collections like this are useful for comparing other implementations,<br>
quickly testing new changes, or as a starting point for new<br>
coverage-directed fuzzing runs.<br></blockquote><div><br></div><div>Thanks for this Greg.  I think this will be very valuable.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
While setting up testing I found that the non-elements harness (e.g.<br>
test.c:test_program) segfaults when elements operations are used and<br>
no transaction context is provided, which is kind of surprising. I<br>
would have expected that either a null tx pointer should always fail<br>
(api misuse) or the elements operations should become cleanly<br>
unavailable.  This might just be me misunderstanding the intended<br>
interface.  But I would have guessed that there would be different<br>
entry points with different required arguments for different kinds of<br>
contexts, and use of the wrong opcodes for your context would just<br>
make execution fail like an executed assertLR node.<br></blockquote><div><br></div><div>The 'test_program' function from 'test.c', and indeed everything from 'test.c' isn't part of the API.</div><div>As you noted already, the API for the Elements application of Simplicity is currently found in 'C/include/simplicity/elements.h' with '<span class="gmail-pl-en">elements_simplicity_execSimplicity' as the primary function.</span></div><div><span class="gmail-pl-en">As one would expect, if you try to pass NULL for the transaction argument to '<span class="gmail-pl-en">elements_simplicity_execSimplicity' the function will immediately return false (API misuse).<br></span></span></div><div><span class="gmail-pl-en"><br></span></div><div><span class="gmail-pl-en">The C library is designed with having application modularity in mind, so that we can easily build other Simplicity applications, e.g. a Bitcoin application of Simplicity supporting Bitcoin-style transactions.  However, at the moment there is only one backend implemented, and there isn't really yet support for multiple backends in the Make system.<br></span></div><div><span class="gmail-pl-en"><br></span></div><div><span class="gmail-pl-en">For all backends, having the transaction context is essentially a requirement, and 'test_program' passing a 'NULL' context is arguably an abuse that only works for programs that do not use any primitives, which is the case for all calls to 'test_program' in 'test.c'.  (The 'test_program' function was developed before the Elements primitives were implemented.)<br></span></div><div><span class="gmail-pl-en"><br></span></div><div><span class="gmail-pl-en">That said, your comment gave me the idea that I could make a "empty" Simplicity application that has no primitives.  This would only really be useful for development and testing, but it would be useful.</span></div><div><span class="gmail-pl-en">With such a backend, attempting to use any primitive would fail cleanly at parsing time.<br></span></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I also found two distinct assertion failures which probably trace back<br>
to a single faulty elements operation. See issues #21 and #22.<br></blockquote><div><br></div><div>Thanks for the report. A PR to fix the issue is under review at <<a href="https://github.com/ElementsProject/simplicity/pull/23">https://github.com/ElementsProject/simplicity/pull/23</a>>.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I was surprised by the rather large percentage of inputs that made it<br>
through type inference. I have no idea how efficient the serialization<br>
will be for actual programs people want to use, but it's at least<br>
efficient for something. :)<br>
<br>
All in all I was pretty impressed by how robust the implementation<br>
appears to be even at this early stage of development.<br>
<br>
I don't, however, think this fuzzing effort is particularly good at<br>
this point. I'm aware of the following shortcomings of my efforts:<br>
<br>* The implementation really needs a static runtime bound for this<br>
testing. With that, I could set it reasonably low, testing would run<br>
much faster, and any test case which still took a long time would be<br>
worth investigating.<br></blockquote><div><br></div><div>I was holding off on this, because there are many DoS vectors that need to be addressed before the Simplicity library is suitable for production use.</div><div>However, thinking about the issue more, I realise that most of the DoS vectors are related to third-party malleability, and only a few are direct DoS vectors.</div><div>It sounds like it would be useful for me to prioritize getting those primary DoS vectors addressed first, and then once those are addressed, move on to third-party malleability issues.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* The success/failure state of each of the vectors in the collection<br>
should be at least checked against another implementation, which I<br>
didn't do. (but someone could do for me, e.g. with the haskell<br>
tools?).<br></blockquote><div><br></div><div>Yes, I will look into evaluating these vectors with the Haskell implementation, and maybe also the Coq implementation for those test vectors that represent well-typed Simplicity programs.<br></div></div></div>