Oh my goodness!

I've been testing things before submit, and there method call at the end of recv_external:

var yay = export_pending_by_pos(0), that shouldn't be there. And the throws. 100 means debug output. That's why transaction was repeated several times - seqno didn't update.

Thanks for pointing out >_>

Throw 100 mean debug. woops.

"The same signature repeated multiple times would be enough to execute an order." There protection against that, and that's not the case.
orders.fc, line 73-89. If user_id has been found - do nothing. contract_utils.fc, line 107-123, if key-ID proving signature - proceed. So by the time of calling add_confirmation_to_order each ID proven to be correct and trusted. Only first ID going to be added.

Thoughts: set_data its merely update of single register, and should be inexpensive. If we group methods by their hi-level purpose. The code going to be more flexible without any major tradeoff's. If my code going to be used by other people, this way is much easier to maintain.

We can reduce set_data calls to just 2, without refactoring (one for seqno update, and second for order processing). Because of assumptions above, I decided pass on that so far. Rule of thumb: each impure method will update set_data.

Trying to squeeze reply.

Yes, I am. My concern was this: the message shouldn't be accepted before every single signature is confirmed. Because then anyone could add random bits at the end, and make contract drain all the funds. That's why I had the logic - if signature valid - throw exception. In my intuition that should lead to message being aborted. Instead I saw exactly opposite - endless retries.

I've learned it hard way: no throws after accept.

So, either there is not enough credit for validation, or it doesn't matter when exactly you accept it. It still vulnerable.

Now I know that the best way is to add one extra sign that validate message with pack of signatures. Then we can check it within credit. But I had no time to add that.