> To me, this seems like a pretty good case for *large* hashcash stamps > combined with a strongish signature/whitelist system. I've already > described, in outline, how such a system could be designed, though some > of the details could stand to be tweaked given recent data. Large > stamps (over 26 bits, possibly as high as 30) would impact spammers' > operations even if they invested in a pile of high-end kit, as they'd > be unable to forge whitelisted signatures in large quantities. > > The signatures, meanwhile, ensure that most users rarely need to > produce such large stamps themselves. This could also begin to make > RPOW more viable for general use, although something tells me it still > won't scale to global proportions. However, use of RPOW would in turn > further reduce the need for end-users to generate stamps, which is > particularly important to users of old machines. > > If this seems interesting, I'll dig out the old posts and distill their > ideas into something more concise and relevant for this month's level > of knowledge. > > -------------------------------------------------------------- > from: Jonathan "Chromatix" Morton I'd be very interested in seeing that. A summary of where things are now (since the goalposts seem to move a little bit every day!). Some points which have been raised include; - Minimum stamp postage values (we've had everything from 20-bits to 30-bits proposed!) - Spammers running powerful minting machines (the stack of Xserves scenario) - Opportunistic signatures (mentioned by eric in his last mail) - Signature / whitelist system - Stamps versus pipe size (again, eric mentioned he had a spreadsheet with some volume calcs. I'd really like to see that) - The 'economic gap' between the Xserve spammer and the poor 486 :) - RPOW (I'd like some background info on this, any links?) - Hybrid systems, and where hashcash fits in (e.g. the MS SenderID proposals, which appear to be gathering pace)