we need some way of counting CLAMour support

[dooglus]

Now that we have people actively supporting CLAMour petitions, we need a way of counting the support, and logging and/or alerting when support for any petition crosses a threshold.

Is anyone working on code to do this?

I figure we want something similar to the stakenotify= clam.conf setting, but am not sure what's best.

The point is that support for a petition may hit 75% (or whatever the trigger point for 'success' is) at some point when nobody's looking, and then fall back again. The client should notice this happening and log (or notify) us about it.

[creativecuriosity]

The original intent had been to avoid parsing it at all in client.
The thought being to avoid the extra resource consumption and possible vulnerabilities that come with storing and validating data.

It isn't by any stretch heavy lifting, and I am not against it, but we should be extra careful to make sure nothing can be exhausted or stressed.

Lighter == Better.

[creativecuriosity]

The fact that the end result ended up being a count over a window, that relieves most of those concerns, I think. Anything beyond the window can simply be dropped, which leaves us with a limited set of data to which even exponential complexity shouldn't be a problem.

[dooglus]

But it's a rolling window isn't it?

ie. blocks 700000 to 709999,
then blocks 700001 to 710000,
then blocks 700002 to 710001,
and so on.

That's what a rolling window is - and so needs to be constantly monitored to see if it every crosses the threshold.

I wrote the above after only seeing your 2nd comment. It's probably best disregarded. I would delete it, but I guess it has already been emailed to you...

[Kefkius]

Until recently I've assumed it could be done with a sort of blockchain parser or explorer. But it seems more peer-oriented to make the measurements consistently repeatable via the core client. I'm not sure how the client should keep track of those measurements though.

[creativecuriosity]

@Kefkius in-chain data is in-chain data; if the 'measurements' aren't 'consistent' and 'repeatable' then we have bigger problems than CLAMour :)

That said, I am not against having all of this functionality in the client.
I just initially avoided it because I was concerned that the complexity would go exponential and expose the network to a DDoS situation - especially given that our fees are still inadequate.

@dooglus The fact that the petition process was created as a rolling window negates this largely.
The only remaining place to keep an eye on is the creation of petitions, given that these happen in transactions and not coinstake speech.

[dooglus]

Implemented in #253, #254, #255, #256.