Re: zombie calculator, messaging without SMTP using identity brokers (Re: response to "proof of work proves not to work"?)

Thank you Eric for the compliment :).
I've now completed a version 2.2 with some economics and an option to 
calculate with the same numbers as those "anti-hashcash researchers" 
used, see attachment.

John Honan: you seem right on the spot! Most probably some zombies can 
be used for minting stamps, some for sending spam, and as long as they 
are not traced, minting+sending in one step is probably the most 
efficient choice for the spammer. And the "good zombies" would imply a 
kind of distributed computing.



Eric S. Johansson wrote:
>> The _only_ difference to current SMTP is the _traceability_ of all 
>> messages.
> the problem here is similar to that of money stamps.  Anytime you have 
> any "currency" that requires a broker, you have a system that can be 
> overwhelmed or corrupted.  Centralized authority 
(aha, identity brokerS provide a multitude of authorities -- easing but 
not eliminating your mentioned problem points)
> means you need to have an evidentiary process for proving someone is a 
> spammer, the judicial process to evaluate the evidence and make a 
> decision whether or not they are spammer, and you need and authority 
> to enforce the devaluing of a currency or currency source.  You also 
> have issues of fundability end reach of an authority.
>
> Each one of the stages are corruptible.  Some very poor countries may 
> be tempted to sell their ID issuers to an external source for 
> management. if ID issuers can be private rather than publicly managed 
> authorities, then nothing will stop spammers from owning their own ID 
> issuer, selling a bunch to the real public and then slipping in their 
> own spammer IDs.
 From what I understood of my email contact with Netmesh, the difference 
to current SMTP is only the _traceability_ of all messages. This can 
bring many brokers with different levels of connection person -- 
internet identity, and according levels of reputation, with 
free+anonymous brokers at the low end, just like what we have today! 
Those people are very into the "social software" ideas and it seems 
trust will be linked with friend and friend-of-a-friend relations to 
regulate the value of one's trust "currency". Spammers will surely 
hi-jack more zombies and owners of zombie-computers will complain to 
their ISP about their messages being bounced.

Hm, so where's the news, what difference from the current situation? Ah, 
_traceability_! (Which also cuts down on phishing for login accounts to 
Paypal and banks) (And maybe ISPs and end-users will get stronger 
incentives to clear up the _traced_ and thus proved-to-be-infected zombies.)

Surely many will send all email with their government-granted identity 
out of habit because it works best, and ignore if the government profile 
your probable voting preferences. Real identity + end-to-end encryption 
(_without_ key escrow, if you are a privacy activist or a dissident) 
would serve most users well, but it would be nice to also have anonymity.

> And also consider what could happen if a government wanted to silence 
> dissenters inside or outside of the country. Either they could tie up 
> the IDs in court or just get them revoked without question depending 
> on the process.
The usage of a broker adds one more layer (on top of DNS on top of 
IP-adresses) where legal regulations and (color)-listing can be applied, 
so let's assume legal attacks will also go for the lower layers, to 
cover all types of messaging at once. As long as you can publish on some 
URL, that URL can be your identity and if you can run software on the 
server, you can be your own broker. Otherwise dissenters would go for 
the free+anonymous servers + stamp their messages! :-)

> so this is why we like stamps.  Nondiscriminatory, decentralized, and 
> annoyingly flexible.
I only dislike the waste of electrical power and that it discriminates 
mobile devices. I think stamps are excellently used in Camram, since as 
I understand one stamp (low power waste :-)) gets you on the white list, 
and one user-report of spam gets you from the white to the black list. 
This gives the majority of legitimate email users a strong factor 
advantage against spammers, and I think it should be more widely adopted.

Trying to remember some situations when someone would need to send email 
to large amounts of previously unknown recipients, I only come up with 
NGOs who collect emails for a new mailing list, or researchers who send 
coupons or other feedback to many of their interviewees. Since this is 
opt-in situations, simplest (but still not simple enough) solution is 
that you must remember to white-list them before they start mailing. 
(Spammers could gather intelligence on current events to figure out 
white-listed senders to impersonate (Paypal scammers comes to mind...) 
but both researchers and list servers would have nothing against using a 
proven identity (either issued by government, ISP, or some group of 
officially known members of the NGO/research lab). Maybe the only 
argument against verified/guaranteed identity of sender is the loss of 
anonymity (where, as I suggested in my previous mail, hashcash-type 
stamps should be an excellent way to get your messages stick up above 
the seas of spam).

> [1] do we have anyone in the audience who works for an ISP or a 
> hosting facility?  It would be interesting to build an anti-spam 
> e-mail service where people become users of stamps and participate in 
> the good zombie culture.  We also need someone to generate the zombie 
> engine and user interface for authentication of requesters for stamps.
About "good zombies" -- isn't it quite impossible to prevent spammers 
from (ab)using the "good zombies" or the ISPs stamp minting resources, 
since legitimate ISP-customers can be converted to bad zombies 
(traceable or not!)? (And ISPs are scared of loose customers so they 
don't shut off zombies.) I think it still boils down to _tracing_ the 
senders, (color)-listing them, and debating when to list or unlist.

In conclusion, I believe we will soon enough get to think more about how 
and where hashcash fits into a system of traceable messaging.

Best regards,
Simon Bohlin

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
  <title>Zombie Calculator</title>
  <script language="javascript">
function calc_stamp_vol(){
//variables
var zombies = document.converter.zombies.value
var attacks = document.converter.attacks.value
var duration = document.converter.duration.value
var pass_rate = document.converter.pass_rate.value/100
var zomb_eff_rating = document.converter.zer.value/100 // percentage to dec fraction
var stamp_capacity = (zombies*zomb_eff_rating) * duration*60
var stamp_volume = pass_rate * attacks/(zomb_eff_rating*zombies)
var stamp_size = 60*60*duration / stamp_volume

//write out results in text boxes
document.converter.stamp_size.value=Math.round(stamp_size*100)/100 //show only 2 decimals
}

function calc_yield(){
//variables
var attacks = document.converter.attacks.value
var pass_rate = document.converter.pass_rate.value/100

var rr_factor = document.converter.rrp.value/100
var unit_yield = document.converter.a_response_income.value

var buyers = Math.floor(attacks*pass_rate*rr_factor)


//write out results in text boxes
document.converter.buyers.value=buyers
document.converter.total_response_income.value=buyers * unit_yield
}


function pow_paper_params() {
  alert('The paper by Laurie and Clayton assumes 4.7*10^10 spams per 24 hours.' 
	+ 'They do some economics on the _sending_ of spam, while these calculations follow their section 4.1 ending suggestion and'
	+ 'goes to the source: the actual income per spam which ultimately decides spam profitability.'
	+ '\n\nNote: Since they don\'t count with zombies, the stamp size value is NOT related to their findings.'
	)
  with (document.converter) {
    attacks.value = 47000000000
    duration.value = 24
		pass_rate.value = 10.0
		
  }
}

  </script>
</head>


<body>

<h2>Zombie Calculator 2.2</h2>
<form name="converter" style="width:70%">

<b>Assume</b> that
<input value="3000000" size=8 name="zombies" type="text"> zombies,
 among which the average efficiency is
<input value="100.0" size=5 name="zer" type="text"> percent <br />
<small>(one recent discussion indicated 40000 zombies working only a few hours per day!)</small>,
are attacking/sending a spam round aimed for <input value="13000000000" size=15 name="attacks" type="text"> mail recipients,
to be completed within a limited time of <input value="24" size=3 name="duration" type="text"> hours, 
where probabilistic filters and other obstacles on average let
 <input value="100.0" size=5 name="pass_rate" type="text"> percent of emails through (but a common estimate is 10%).
<small style="color:gray;">When spammers start stamping they'll try to stamp only where the effort can pay off, i.e. those mails that won't get through without stamps. 
From this perspective, the calculation below bravely assume that all mails that get through the filters are stamped mails, i.e. the whole planet implemented hashcash!</small> 
<br />
<br />

Click the button 
<input value="calculate stamp size" onclick="calc_stamp_vol()" type="button">
to see the minimal 
<input value="" name="stamp_size" size=8 type="text"> stamp size in seconds <small>(2 decimals)</small> 
where the cost of stamp minting starts to limit spam
(the attacker cannot spend as much stamps as needed and must start skipping stamping some recipients, which in effect means those spams never get through the spam filters)

<br />
<br />
<b>Economical calculations</b> <small>(See further the paper "<a href="http://www.cl.cam.ac.uk/~rnc1/proofwork2.pdf">Proof of work proves not to work, version 0.2</a>" <input type=button value="fill in their parameters" onclick="pow_paper_params()">)</small>
<br />
Assume further a <input type="text" value="0.003" size=5 name="rrp"> percent response rate among those
where the spam got through the filters (some wild estimates are that 0.003% of spam recipients buy from the spammer) 
worth on average <input type="text" value="4.0" size=4 name="a_response_income"> dollars (or any currency unit).
<br />
Click to 
<input type="button" value="calculate spammer yield" onClick="calc_yield()">
 which amounts to <input type="text" value="" size=10 name="buyers"> buyers and a grand total of 
<input type="text" value="" size=16 name="total_response_income"> (currency as above) for one spam round.

</form>

<br />
<br />
<b>From stamp time to processor time</b><br />
Stamp costs above are measured in time, but computers have differing efficiency at minting stamps.
A science paper (<a href="http://www.thefengs.com/wuchang/work/courses/cs576_spring2005/crypto03.pdf">Dwork, Goldberg, Naor</a>)
assumes that spammers/attackers can have processors 30 times more efficient than the slowest
home computers which are in internet use. 
The same paper instead propose a memory speed (latency) -bound method with suggested factor 4 
between the faster and slower computers in use.
Add mobile devices used for messaging and the factor gets _much_ bigger in processor speed 
and but as they claim not too much worse in memory latency. Their (current known) main disadvantage seems to be 
a minimum addition of a few kilobytes to the message size, but with (color)-listing these kilobytes could be 
necessary only for the first mail in an email conversation (or mailing list!).
Anyway, speed factors are "academic" as long as attackers have huge zombie farms that can both
mint stamps and send out their spam.
The bottom line is what stamp time is needed to cut off some spam, how much spam it cuts off, 
and the end-user cost for getting such a system going.

</body>
</html>