Unicode is the next 3|_33+ 5P34|<
Bored with being eleet on IRC? Why not take a look at the forthcoming 32-bit eleetness brought to you by Unicode(TM)(R)? At the Shoestring Foundation Labs, where we invented time machines long before H.G. Wells could think of one, we are in the process of converting boring old ASCII to totally eleet Unicode. See our example page!.
Extended Euclidian Algorithm in dc(1)
If you think you're really bored than guess how bored I was when I wrote The Extended Euclidian Algorithm in a one-line shell script. Ok, it's a long line (160 chars in the dc part), but it runs on every POSIX compliant system and works on arbitrarily large numbers.
In contexts like remailers it is impossible to have the originator of a message solve puzzles interactively. But with quasi-synchronous clocks (exact up to a few hours perhaps) and a small database, it is possible to implement offline Hashcash. Such a Hashcash Check looks like:
HashCheck Version: 0.1 To: email@example.com Bits: 12 Comment: test Date: 1015030975 Rand: 1530c9285266d00f260983b793861dfd Hash: 001110111111
It is bound to a recipient (firstname.lastname@example.org) and a date, so presenting the same check to other parties or to the same party after a certain period of validity will fail. For the period of validity the recipient has to store the Rand value and compare incoming Hashcash Checks against the list of received checks. If the Rand is on the list or the date outside the validity, the Hashcash is ignored. And it's all implemented in Perl. Adam Back has a similiar scheme with shorter messages intended to be embedded in headers of other protocols.
Also called Client Puzzles. HashCash is used to prove expenditure of computing power. This is interesting for flooding control, e.g.SMTP Server:
You want to send this email to 10.000 recipients? Well, pay 12 bits of HashCash for each one.
Spammer's MUA: Alright, forget about it.