SPEK – a killer app for Bitcoin – Spam and Phishing Emails Killer
By requiring every email sender to maintain a bitcoin address with a small balance in it, spam and phishing could become a thing of the past. The amount (value of, say, 1 cent) is never spent, but must exist for any email address that an email is sent from. Spammers using millions of ‘from’ addresses would have to fund millions of small balances.
This is an outline proposal that needs further work. Please feel free to suggest improvements.
The basic idea is that the sender of an email maintains a nominal balance in a bitcoin address (the “spek” address) set up for specifically for this purpose. The sender retains the private key to the spek address, and should only have to fund it once.
A separate provably unspendable bitcoin address (the “sentinel” address) created from the sender’s address would allow a recipient of email related to that spek address to flag it as spam.
A spammer would be faced with the problem of his sentinel addresses constantly being flagged and becoming useless. The only way to get spam through would be to set up millions of spek addresses, and funding them. This should prove economically non-viable.
We’ll use the usual suspects, Alice and Bob. (The processes described as being performed by them would in reality be carried out by their email providers or email client.)
Suppose Alice wants to send an email to Bob.
Alice has previously set up a randomly generated bitcoin address (spek address) to which she holds the private key.
She has also previously paid a small amount into the spek address, say the equivalent of a penny. All being well she should only ever have to do this once.
Alice writes her email, and then digitally signs some unique element of the email (eg the subject or the time of sending) using the private key of the spek address. She includes that signature and the public key of her spek address at the end of the text of the email, .
Bob receives Alice’s email.
He first confirms that the signature matches the relevant data (ie the subject or time of sending) in the email, using Alice’s public key. This proves that the sender of the email possesses the private key of the public key.
If this test fails, he deletes the email and ignores it. It was not sent by the person claiming to be the sender.
He then generates Alice’s spek address from the public key, and its sentinel address.
He then checks the sentinel address of Alice’s bitcoin address. The sentinel address is a provably unspendable bitcoin address created from Alice’s bitcoin address (see technical details below).
(See below for a discussion of how the sentinel address might work)
If the sentinel address shows clearly that this is a spammy spek address, the email can be rejected.
Bob then looks up the balance of the spek address, and checks that it’s equal to or greater than the agreed threshold (say a penny).
If the balance is insufficient, he can either ignore the email or place it in a spam folder for later review.
If the email makes it through these checks but Bob determines that it actually is spam or a phishing email, Bob can flag the sender’s sentinel address, possibly using a third party service.
Operation of the sentinel address
This piece needs further thought, although I think I have the basic concept right.
Micropayments, as small as 1 satoshi, to the sentinel address could be used to flag that address as having been used in a spam email.
Individual wishing to flag a spek address as a spammer would make micropayment from their own spek address.
A sentinel address could then be assessed based on the characteristics of the address that had made payments to it.
For example if there were several recent payments from spek addresses whose own sentinel accounts were empty, that would be a strong indication that this sender was indeed a spammer.
Note that payments made to sentinel addresses would be permanently lost. See “Practical considerations” for some thoughts about who should actually bear the cost of these micropayments.
How to derive the sentinel address of a spek address
We use the process described on this page, but we replace the value calculated in step 3 (the 24 byte RIPEMD-160 hash) with the first 24 bytes of the SHA256 hash of the spek address string.
If the spek address is 1FyfFouKXHbqg2AknTcSRdDQKE4ujt7vGX
> fakeRIPEMD160 = “00” + Crypto.SHA256(“1FyfFouKXHbqg2AknTcSRdDQKE4ujt7vGX”).substring(0, 48)
> checksum = Crypto.SHA256(Crypto.util.hexToBytes(Crypto.SHA256(Crypto.util.hexToBytes(fakeRIPEMD160)))).substring(0, 8);
> Bitcoin.Base58.encode(Crypto.util.hexToBytes(fakeRIPEMD160 + checksum));
This gives a sentinel address of 1GFpUwdgmQT1bRuXjd9pJb94v3MGPSPR5xVmuLH
This address is provably unspendable since there is no way to find out a private key that points to it.
Practical considerations and further research required
1) Alice could perhaps lodge her private key with her email provider, eg gmail, yahoo. Since there’s only a tiny amount of money in it, this does not consitute a risk.
2) Further thought is required into the details of how the sentinel address would work. Ideally it shouldn’t cost an individual to report a spammy spek address. Possibly some non-profit organisation could manage this. Or maybe an autonomous agent funded via charitable donation could recompense individuals who report spam.
3) A point to consider in the sentinel system is that scurrilously marking an innocent party’s email as spam should have no effect. Ideally a number of reports (ie micropayments) from reputable spek addresses would be required to actually flag an address as a spammer.
4) Whilst a penny is not a large amount of money to most people in the developed world, it is important that the poor should not lose access to free email. To this end perhaps a charitable organisation could be set up to ensure that email did not become the exclusive preserve of the better off. Such a charitable organisation could also take the lead in promoting the spek idea. A public figurehead would be useful – perhaps someone like Bill Gates, Paul Graham, or maybe two of the more obvious beneficiaries of bitcoin’s rise, the Winklevoss twins.
5) Adoption. Initially this could be a voluntary protocol, phased in over a couple of years, with a final switch-on date when all major email providers were already offering it.
As stated at the beginning, this is just an outline idea. Please feel free to add suggestions in the comments below.
1SPEKXiV6NF9Xg6Ridw2qUtV83T8TRJZZ (donations, if there are any, will be given to some charity or other at some point – I won’t keep them)