Quote from: Evil-Knievel on April 12, 2017, 04:43:44 PM

Quote from: Evil-Knievel on April 11, 2017, 08:38:08 PM

Quote from: coralreefer on April 11, 2017, 08:04:18 PM

Quote from: Evil-Knievel on April 11, 2017, 05:39:27 PM

Just thinking out loud: do we really need the bounty announcements in the new SN scheme?

It depends on how well the SN can handle a huge volume of submissions...but I believe it will have to do this either way.

Yesterday, I submitted a job that had an issue which allowed every pass of the interpreter to find a "Bounty", so the miner tried to send hundreds of submissions pretty quickly....this is something anyone could do (i.e. create a simple job that allows legitimate bounty submissions to spam the SN).

So I thought your original design had a small fee on each of these submissions, along with the announcement in order to deter this kind of behaviour. But if you have another approach that simplifies things, I'd be all for it.

Well, first of all a job has a natural bounty limit ... submissions beyond this level are not permitted. But of course, there is a grace period between the submissions and their actual inclusion in the blockchain (or its unconfirmed transaction cache). In this time window it is possible to flood as much as you can. We could add a "SN rate limit" which would allow not more than x transactions per node per second.

What sucks more is the lack of direct feedback from the SN. Since we queue at the moment, the miner does not even know if his submission was dropped, accepted or denied. We really have to think this through! Is queuing the right way to go at all?

Btw: I could reproduce your bug today. I just could not yet find out why it happens.

Fixed that bug. We will have to make sure that hashes and multiplicators are at most 32 bytes long ... not 33 like it could happen before.

Fix is here: https://github.com/OrdinaryDude/elastic-core/commit/b95596e572af659cb7355a68643a58098579109f
Extra checks in API are here: https://github.com/OrdinaryDude/elastic-core/commit/4870aa5c22786e27fbfdc37665a45e82f99410c9

Do not use that yet!

Hi EK, can you please confirm if this was due to something the miner sent or is it an issue in only the core server? I checked the miner code and I don't see how it could send more than 32 bytes.