Use trivial algorithm in ecmult_multi if scratch space is small

[jonasnick]

ecmult_multi already selects the trivial algorithm if the scratch space is NULL. With this PR the trivial algorithm is also selected if the scratch space is too small to use pippenger or strauss instead of returning 0. That makes it more easier to avoid consensus relevant inconsistencies just because scratch space construction was messed up.

[real-or-random]

I think that's a good idea. But the drawback is that now you won't notice that you use the slow algorithm. Do you think we can somehow get the best of both worlds, i.e., fall back to the trivial algorithm but somehow indicate that something is wrong? I don't see a convincing way to do this:

• we cannot just print a warning from the library
• we can't use the current callbacks because they'll abort the process (and introducing another callback for that single case is probably overkill)
• maybe using a second non-failing return value? (also not great and changes the API)

[jonasnick]

But the drawback is that now you won't notice that you use the slow algorithm

You have that problem anyway even without this PR because you can have a scratch space which only fits a single point. Or if you make a scratch space fitting 2 points but you have a 1000 to multiply.

You'll notice that you're using a slow algorithm if you benchmark your program which presumably you do if you use ecmult_multi or batch_verify. You might have a problem if the size of the scratch space is attacker controlled and you assume something about timings of ecmult_multi, but this PR is a strict improvement in that case. I don't have anything against multiple return values per se, but it's not a panacea because you need to make implementer check for the various error types.

[real-or-random]

utACK

[gmaxwell]

Concept ACK.

I share the concern that users will get poor performance by surprise, but I think the right way for us to address that would be to in the future provide an API that doesn't require manual scratch space handling, even at the expense of wasting memory. "Fast by default".

In the absence of that, I'd much rather it fail slow than fail fail.

[real-or-random]

utACK 9ab96f7