Bounty proposal for a Bitcoin-based email to fight spam.

[cbeast]

Let's say you are willing to publish your email address publicly, but you don't want to have to keep track of who your friends are, nor want to become part of a spam list. As to date, there are NO reliable spam filters because for every scheme devised, there are ways to counter them. It's getting to the point when one must go through spam to find an important email. Spammers are like roaches and can never be eliminated by conventional means. Let's take away their incentive to operate.

Hashcash is a good idea, but monetizing email can open up new markets.

Enter Bitcoin-based email. There will be a big demand for an email application that requires a nano-payment "postage" to receive an email. The transaction can be small enough that it would be no burden to any individual, but at least an irritating inconvenience to spammers. It could also be integrated with standard email, but paid email would be given top priority.

As far as the bounty is concerned, I'm not qualified to judge code, so I'll leave that to any dev willing to volunteer.

I'll make this a poll so that even if you are not able to donate to the bounty, nor contribute any thoughts to the idea, you can show support for the idea. Also, if you didn't know, by using a poll you don't need to post "subscribe" nor go to your email to see if there is an update to this thread.

Finally, I know this idea has been discussed before, but I have seen no progress lately. Hence, the bounty proposal.

[1715188982]

1715188982

[1715188982]

1715188982

[1715188982]

1715188982

[jjjrmy]

Awesome idea!

[2_Thumbs_Up]

Enter Bitcoin-based email. There will be a big demand for an email application that requires a nano-payment "postage" to receive an email. The transaction can be small enough that it would be no burden to any individual, but at least an irritating inconvenience to spammers. It could also be integrated with standard email, but paid email would be given top priority.

At first I was going to say that the bounty needs just to be higher than the cost of sending an e-mail with regards to electricity, bandwith etc. But this is obviously wrong since most spammers probably don't pay for this themselves.

So the bounty needs to be higher than the monetary value of one spam mail, so that spammers would rather keep their bitcoin than to send the mail. This is still very low, since the value of spam comes from bulk sending.

We would need a good method for nanopayments though, since spamming the network with this would be a bad idea. Maybe the probabilistic payment method would be good for this.

[Meni Rosenfeld]

This is a move that I support, but I think you're too optimistic with respect to demand. Hashcash serves the same purpose (albeit less effectively) and its adoption is very weak. Network effects are strong here, it will only be effective if most people use it.

At first I was going to say that the bounty needs just to be higher than the cost of sending an e-mail with regards to electricity, bandwith etc. But this is obviously wrong since most spammers probably don't pay for this themselves.

So the bounty needs to be higher than the monetary value of one spam mail, so that spammers would rather keep their bitcoin than to send the mail. This is still very low, since the value of spam comes from bulk sending.

Of course it needs to be higher than the value of the spam email - on one side you have the costs (Bitcoin, bandwidth if paid, etc.), on the other you have the value of the mail to the spammer. The costs need to be higher than the value to prevent the sending.

We would need a good method for nanopayments though, since spamming the network with this would be a bad idea.

I don't think it's going to be a problem, the value of a legitimate email outweighs the cost of propagating a transaction. Even if not there are many possible solutions.

[cbeast]

Let me define what I mean by bounty. I'm talking about raising funds for development. In the case of the cost of sending a nano-payment for email, then yes just a minimum amount should suffice. Maybe 0.001 BTC is nothing for an individual, but for a spammer that sends many thousands of emails it would add up.

We would need a good method for nanopayments though, since spamming the network with this would be a bad idea. Maybe the probabilistic payment method would be good for this.

Probabilistic payments would be great, but so far it's only a hypothesis. AFAIK there isn't even a proof-of-concept for probabilistic payments yet. We could just as well use Ripple or LETS. As far as spamming the network goes, I guess we'll need to use whatever minimum fee will be accepted by miners.

[DeathAndTaxes]

It is interesting and I would use it if such a system already exists and had a large enough network.

The two largest problems are:
a) network effect.  if 1% of my legit emails are on the network it does very little good.  I still need to do massive filtering to find the other 99% "legit but not on network emails"
b) micropayment issue.

On the micropayment issue there already are non-payment proposals to prevent spam involving PROOF OF WORK.  Essentially when someone emails you then need to performs a certain amount of work (few seconds of CPU time on avg computer) and sign the email.  The main problem is the network effect.  If only 1% of your legit emails are using such a system it isn't effective.

Most spam solutions would work if they had a large enough network effect.  By using Bitcoins you are simply swapping coins = manifestation of work already completed with direct proof of work.  The same network effect limit exists.  So even if you accept that generally speaking PROOF OF WORK is a valid defense against spam you have to look carefully at the INCREMENTAL BENEFIT and INCREMENTAL COST of using bitcoins vs native proof of work.

For example bitcoins would allow a "weak system" (like say a tablet) to send email as quickly as a powerful workstation but it adds the "cost" of handling micropayments.  The question becomes does the complexity of micropayments outweigh the "cost" of ipad user having emails delayed say 7 seconds while they complete the PoW?  At first glance I would say ... no but am willing to hear some arguments.


Note: proof of work is a theoretical defense to any systems where the "attack" is "cheap" by increasing the cost of the attack.
http://en.wikipedia.org/wiki/Proof-of-work_system

[DeathAndTaxes]

Having a vote option of "maybe, undecided would be useful".  If forced to pick right now I would just say "No" as I don't see value of Bitcoins over native PofW.  Still I will just abstain because there may be some merit.

[Meni Rosenfeld]

Having a vote option of "maybe, undecided would be useful".  If forced to pick right now I would just say "No" as I don't see value of Bitcoins over native PofW.  Still I will just abstain because there may be some merit.

I think you're forgetting that the spammer will not use a CPU, he will use a dedicated hashing device. Which means that the difficulty will need to match the dedicated device, so a legitimate user can't use his CPU. He will need to use an external service, which adds more overhead and fallibility to the system. With Bitcoin payments, the user will just use whatever Bitcoin solution he's already using.

[DeathAndTaxes]

Having a vote option of "maybe, undecided would be useful".  If forced to pick right now I would just say "No" as I don't see value of Bitcoins over native PofW.  Still I will just abstain because there may be some merit.

I think you're forgetting that the spammer will not use a CPU, he will use a dedicated hashing device. Which means that the difficulty will need to match the dedicated device, so a legitimate user can't use his CPU. He will need to use an external service, which adds more overhead and fallibility to the system. With Bitcoin payments, the user will just use whatever Bitcoin solution he's already using.

Well scrypt would be an option.  Possibly one with a massive lookup table which requires significant amount of memory.  This would make dedicated devices difficulty.  Any protocol could also support changing hashing protocol significantly enough every say 12 months to make cost of ASIC development prohibitive.

Still I agree now there would be some merit to using Bitcoin, it effectively prevents the scammer from getting a shortcut.  If they could mine coins faster then they don't need to spam.    The micropayment issue is still a steep one.  So it comes down to does the flexibility of Bitcoin based system have higher utility.

On edit: While writing I thought over another advantage of Bitcoin.
The rise of "lite clients" also make any work based solution hard to get off the ground.  I use gmail so any PofW isn't done by me it is done by google.  The PofW for 2 million legit users is staggering and I doubt that is a cost google wants to deal with.  That means google is less likely to embrace PofW system and the network effect suffers.  Using Bitcoin the cost (negigible as it is) is paid by the user so there is no pass through cost to Google other than implementation.

[etotheipi]

On the micropayment issue there already are non-payment proposals to prevent spam involving PROOF OF WORK.  Essentially when someone emails you then need to performs a certain amount of work (few seconds of CPU time on avg computer) and sign the email.  The main problem is the network effect.  If only 1% of your legit emails are using such a system it isn't effective.

Most spam solutions would work if they had a large enough network effect.  By using Bitcoins you are simply swapping coins = manifestation of work already completed with direct proof of work.  The same network effect limit exists.  So even if you accept that generally speaking PROOF OF WORK is a valid defense against spam you have to look carefully at the INCREMENTAL BENEFIT and INCREMENTAL COST of using bitcoins vs native proof of work.

Many years ago I was a proponent of the pay-for-email scheme, and thought it was a brilliant idea.  I never thought of it again since Bitcoin became real, so I was excited to see cbeast's recommendation.  But I do agree:

(1) That's a lot of transaction volume on the network.  I think Bitcoin clients needs to have better blockchain management/pruning schemes before anything like this could ever be attempted.  Or find a way to aggregate the payments (like the hashcoin solution involving locktimes and replacement, so that you can make thousands of micropayments off network, as long as both parties have a persistent financial relationship...)

(2) DeathAndTaxes is absolutely right.  The Bitcoins are kind of an roundabout way to solve the problem:  might as well just use proof-of-work directly.  I like the idea of requiring emails (with sender, recipient and date) to require a nonce that gives the hash of the email X leading zero bytes.  In Bitcoin, X=4 is the same as difficulty-1 calculation.  Even if it was just X=2 or 3, most computers and devices can do that computation very quickly.    

Either way, users would need to make sure that their ISP or email server supports this.  I could see many midstream providers implementing this, then selling out to allow a single proof-of-work to distribute multiple emails for some BS reason that doesn't make sense to anyone but the spammers.

Actually, I can think of one legitimate reason:  if you write a lot of emails on your smartphone, having any proof of work acceptable for desktop computers would probably take a few seconds and quite a bit of battery life.  So perhaps, the data service provider skips the check or performs proof of work for you for a fee?  But then that would quickly turn into a game of making exceptions to the PoW rules that spammers will learn to exploit.

I don't know, but there's a lot of possibilities here.  Whether you're paying in computation time or money, it's very easy to find a threshold that is basically transparent to the majority of legitimate users sending <20 emails a day, but is prohibitive to the spammers sending millions.

EDIT:  Hell, we don't even need Bitcoin or anything else to sign onto the idea of using proof of work.  Your email client could do it all for you (since verifying PoW is super-fast, and a scrypt-like CPU "hasher" is easy to implement in arbitrary software).  Once a certain level of adoption is reached, you could just turn off your ISP spam filter entirely and your email client filters out everything that doesn't have PoW.

[kjj]

Your post advocates a

(X) technical ( ) legislative ( ) market-based ( ) vigilante

approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.)

( ) Spammers can easily use it to harvest email addresses
(X) Mailing lists and other legitimate email uses would be affected
( ) No one will be able to find the guy or collect the money
( ) It is defenseless against brute force attacks
( ) It will stop spam for two weeks and then we'll be stuck with it
(X) Users of email will not put up with it
(X) Microsoft will not put up with it
( ) The police will not put up with it
( ) Requires too much cooperation from spammers
(X) Requires immediate total cooperation from everybody at once
(X) Many email users cannot afford to lose business or alienate potential employers
( ) Spammers don't care about invalid addresses in their lists
( ) Anyone could anonymously destroy anyone else's career or business

Specifically, your plan fails to account for

( ) Laws expressly prohibiting it
( ) Lack of centrally controlling authority for email
( ) Open relays in foreign countries
( ) Ease of searching tiny alphanumeric address space of all email addresses
( ) Asshats
( ) Jurisdictional problems
(X) Unpopularity of weird new taxes
(X) Public reluctance to accept weird new forms of money
( ) Huge existing software investment in SMTP
( ) Susceptibility of protocols other than SMTP to attack
( ) Willingness of users to install OS patches received by email
( ) Armies of worm riddled broadband-connected Windows boxes
( ) Eternal arms race involved in all filtering approaches
(X) Extreme profitability of spam
( ) Joe jobs and/or identity theft
( ) Technically illiterate politicians
( ) Extreme stupidity on the part of people who do business with spammers
( ) Dishonesty on the part of spammers themselves
( ) Bandwidth costs that are unaffected by client filtering
( ) Outlook

and the following philosophical objections may also apply:

(X) Ideas similar to yours are easy to come up with, yet none have ever
been shown practical
( ) Any scheme based on opt-out is unacceptable
( ) SMTP headers should not be the subject of legislation
( ) Blacklists suck
( ) Whitelists suck
( ) We should be able to talk about Viagra without being censored
(X) Countermeasures should not involve wire fraud or credit card fraud
( ) Countermeasures should not involve sabotage of public networks
(X) Countermeasures must work if phased in gradually
(X) Sending email should be free
( ) Why should we have to trust you and your servers?
( ) Incompatiblity with open source or open source licenses
( ) Feel-good measures do nothing to solve the problem
( ) Temporary/one-time email addresses are cumbersome
( ) I don't want the government reading my email
( ) Killing them that way is not slow and painful enough

Furthermore, this is what I think about you:

(X) Sorry dude, but I don't think it would work.
( ) This is a stupid idea, and you're a stupid person for suggesting it.
( ) Nice try, assh0le! I'm going to find out where you live and burn your
house down!

[Meni Rosenfeld]

@kjj Nice strawman you put up there. You're imagining a very limited way to use this.

Whitelisted senders will of course not need to send bitcoins/PoW. This solves the mailing list and some other issues.

Until everyone uses this, of course the receiver will not reject all messages that don't have payment. Rather, it will be used to accept messages that would otherwise be mistakenly spamfiltered, which also means that the spam filter can be a bit more aggressive (because those who really want to send a mail to you can do it by sending payment). Going forward it will start deprioritizing paymentless messages, then warn senders that the recipient wants payment for messages, and only after it's a global standard, reject messages without payment.

Also, "Sending email should be free" is stupid, and the amount of payment under consideration here is for all intents and purposes free.

[Mike Hearn]

The problem of fighting spam is not an economic one, it's about segregating and classifying mail streams correctly.

I work on the Gmail abuse (outbound spam) team. Forcing people to pay with money or resources to send spam will not work. The bulk of spam leaving Gmail these days comes from compromised accounts that are being accessed from compromised computers. At no point does the spammer ever use their own resources. Your scheme would just push even more pain onto victims of poor security practices.

Despite that cold reality, "report spam" markings are at an all time low for our userbase because traditional approaches to fighting spam do work. Authenticate your mail to make separation of streams easier. Calculate reputations on those mail streams. If somebody clicks report spam degrade the reputation. If people receive mail and read it/don't report it, increase the reputation. The principle is straightforward enough and the implementation is easy.

99% of the rest of the Gmail spam filtering code is for what you might call backwards compatibility - how to handle mail streams that do not authenticate themselves properly but still need to be classified correctly, and going deeper into divergent mailstreams to handle the case where, eg, a major mail sender gets hacked, or when your friends get hacked and spam you, or when a large webmail providers signup security fails and you get 10,000 spammy accounts sending from the same network as 1,000,000 good users.

[cbeast]

@ Mike Hearn - I 95% agree with you, but most people are too lazy or ignorant to manage their spam. Besides, I'm not suggesting a replacement system, just a way to bypass spam filters.

So far I'm seeing that folks think this may be a good idea, but not yet. I suppose more exploration into the efficacy of probabilistic payments is needed. I haven't seen scheme that would be universal enough for wide acceptance. Maybe email will end up in the domain of social networking for anti-spam solutions. At some point, money and social networking will also probably converge. Perhaps probabilistic payments processed by social networks can lead to whitelisting.

[FreeMoney]

The problem of fighting spam is not an economic one, it's about segregating and classifying mail streams correctly.

I work on the Gmail abuse (outbound spam) team. Forcing people to pay with money or resources to send spam will not work. The bulk of spam leaving Gmail these days comes from compromised accounts that are being accessed from compromised computers. At no point does the spammer ever use their own resources. Your scheme would just push even more pain onto victims of poor security practices.

When attackers get a hold of a normal CPU they can use it to send email or (I guess) sell it to someone who will use it to send email. When they get a hold of Bitcoins they can use them for tons of other things, they won't squander the coins they find/steal on something worth less than the coins because they didn't pay for them. Just set the price above value and almost all spam would stop.

But still 99.999% of people don't have coins so you'll have to see and whitelist all unknown address email anyway... so not workable now I think.

[kjj]

@kjj Nice strawman you put up there. You're imagining a very limited way to use this.

Whitelisted senders will of course not need to send bitcoins/PoW. This solves the mailing list and some other issues.

Until everyone uses this, of course the receiver will not reject all messages that don't have payment. Rather, it will be used to accept messages that would otherwise be mistakenly spamfiltered, which also means that the spam filter can be a bit more aggressive (because those who really want to send a mail to you can do it by sending payment). Going forward it will start deprioritizing paymentless messages, then warn senders that the recipient wants payment for messages, and only after it's a global standard, reject messages without payment.

Also, "Sending email should be free" is stupid, and the amount of payment under consideration here is for all intents and purposes free.

It is a joke.  And old, old, old joke.  You were supposed to laugh.

The problem with spam, as pointed out by others before me, is that spammers are already not paying the cost of sending mail.  What makes you think they will start paying for it when you make it more expensive?  Why wouldn't they just keep using stolen resources like they do now?

[etotheipi]

The problem of fighting spam is not an economic one, it's about segregating and classifying mail streams correctly.

I work on the Gmail abuse (outbound spam) team. Forcing people to pay with money or resources to send spam will not work. The bulk of spam leaving Gmail these days comes from compromised accounts that are being accessed from compromised computers. At no point does the spammer ever use their own resources. Your scheme would just push even more pain onto victims of poor security practices.

When attackers get a hold of a normal CPU they can use it to send email or (I guess) sell it to someone who will use it to send email. When they get a hold of Bitcoins they can use them for tons of other things, they won't squander the coins they find/steal on something worth less than the coins because they didn't pay for them. Just set the price above value and almost all spam would stop.

But still 99.999% of people don't have coins so you'll have to see and whitelist all unknown address email anyway... so not workable now I think.

A straight proof-of-work system would actually be usable if Mike Hearn hadn't pointed out that spammers frequently are not limited by resources.      It would be very easy to make a email plugin that calculates a PoW for all outgoing mail and verifies it on all incoming mail.  And, it would only unblock incoming mail instead of rejecting stuff that didn't use it.  It could sit mostly-usused until it is widespread enough that people could start scaling down their regular spam filters knowing that all their legit mail will have a PoW.

The other advantage of PoW is that it doesn't require money.  My concern with a micropayment scheme is the ease with which people will figure out how to empty your email wallet and thus not let you send mail, or the complication of typing in your password in just to send an email, because you want to avoid the previous inconvenience.

I'm personally starting to believe that this is theoretically a great idea, but fails in practice.  In many ways...

[phelix]

somebody (vinced) is/was working on a namecoin based messaging system.

right now you could already transfer a pre registered name with a variable (preferably encrypted) value of up to 1023 bytes for standard network fees. the fee currently can be free, but you could simply disregard too low fee transfers.

if you want the fee to go to the recipient you could do something like this shortly after sending the mail:

    namecoind name_send spamcontrol/sathosi@bitcoin.org 1.0

the mail must include the sending namecoin address for verification - only the first is valid.
(name_send is currently only available in my dreams and python wrapper)

sorry to again come up with namecoin but I really think it has plenty of potential and adds many possibilities to the block chain.

[cbeast]

somebody (vinced) is/was working on a namecoin based messaging system.

right now you could already transfer a pre registered name with a variable (preferably encrypted) value of up to 1023 bytes for standard network fees. the fee currently can be free, but you could simply disregard too low fee transfers.

if you want the fee to go to the recipient you could do something like this shortly after sending the mail:

    namecoind name_send spamcontrol/sathosi@bitcoin.org 1.0

the mail must include the sending namecoin address for verification - only the first is valid.
(name_send is currently only available in my dreams and python wrapper)

sorry to again come up with namecoin but I really think it has plenty of potential and adds many possibilities to the block chain.

I know, right? With merged mining, namecoin is as robust as it is useful. Thanks for that.

[paraipan]

Would be nice to have a "Generate stamp" in the bitcoin software and get it funded with btc cents before you paste it in your e-mail. It would get relayed between servers that trust each other to share the fees, just like a WoT. The users could chose to let e-mail without stamps pass through or not. Post Office 2.0, yay