There is not yet a design that would fulfill all these criteria. The main problem seems to be that "block a spam source that spammed other Spamikaze instances" requires a push model, while getting a second opinion on an IP address is more suitable to be implemented as a pull model. If you have an idea on how to get this fixed, please write it down here:
Push versus pull do not necessarily exclude each other. Imagine a Spamikaze message-bus on which it is possible to push spam-trap hits and additional details and requests about a certain IP-address' reputation. This requires additional design goals that have to be met:
prevent spammers from either tarnishing a certain IP's reputation (Joe Job) or from getting a handle on the survivability of their spam-run, as often happens with SpamAssasin and;
<application_type>SMTP</application_type> (for the time being only SMTP, but distributed Spamikaze could potentially be enhanced for other malicious attempts to use a TCP/IP based service, for example exploits of HTTP-server vulnerabilities)
The message also should be be cryptographically signed by the sender node. To discuss: should the unix_time_of_hit and the application_type not be encrypted using the announcer's public key and have the announcement take place at a random delay in order make detection of spam traps more difficult?
Each node that is not the originator of a request should add a cryptographically signed report of the number or requests it has received from the requesting party in the past hour and remove such reports from previous nodes in order not to reveal the topology of the distributed Spamikaze network.