Author

Topic: Decentralized, Bitcoin-based anti-spam solution (Read 181 times)

legendary
Activity: 3906
Merit: 6249
Decentralization Maximalist
This seems to be focusing on the "sender" side of the story. Spammers don't have an incentive to use these providers, they will just fine one that is spam-friendly and use it.
At the contrary ... it focuses on the provider and its cost on fighting spammers.

The reason why the privacy-aware services I mentioned in the OP are discontinuing services is because their costs to fight spammers become too high. With the proposed system, as you say, they wouldn't use these service anymore because of the high costs (both in logistics and for financing the "security deposit") - and the goal would have been achieved.

On the long term, if more small email providers used a similar solution (bigger providers already use well-working, but very expensive mechanisms) then the spam problem could even be diminished globally, as spammers would have an increasingly hard time to find a suitable provider.
jr. member
Activity: 107
Merit: 7
This seems to be focusing on the "sender" side of the story. Spammers don't have an incentive to use these providers, they will just fine one that is spam-friendly and use it.
legendary
Activity: 3906
Merit: 6249
Decentralization Maximalist
If you idea was really implemented,99% of your customers would run away from your service and switch to the "free" spam-friendly services. Grin
Nobody wants to send bitcoins to an escrow address just to use an email service.It's just isn't convenient and user-friendly.Phone or ID verification can do a way better job with fighting spammers.
In addition to what HeRetiK already wrote, ID verification is very expensive (you would have high labor costs) and phone verification is possible to get "gamed" by scammers with throw-away numbers. It could be an option for the provider, though, to offer phone verification and the proposed "Bitcoin deposit proof" in parallel - so privacy-aware customers could select the Bitcoin deposit method and all others the phone verification.

And the concept does not require an escrow. The coins are still fully under your control, even in the variant with CLTV.
legendary
Activity: 3122
Merit: 2178
Playgram - The Telegram Casino
If you idea was really implemented,99% of your customers would run away from your service and switch to the "free" spam-friendly services. Grin
Nobody wants to send bitcoins to an escrow address just to use an email service.It's just isn't convenient and user-friendly.Phone or ID verification can do a way better job with fighting spammers.

OP mentioned above that this approach would target a privacy-centric userbase for which phone or ID verification are not an option. While the majority of users don't care about their privacy and personal data there's definitely a need for less intrusive anti-spam measures.
hero member
Activity: 3164
Merit: 937
If you idea was really implemented,99% of your customers would run away from your service and switch to the "free" spam-friendly services. Grin
Nobody wants to send bitcoins to an escrow address just to use an email service.It's just isn't convenient and user-friendly.Phone or ID verification can do a way better job with fighting spammers.
legendary
Activity: 3906
Merit: 6249
Decentralization Maximalist
Most large email providers already apply (centralized) anti-bot measures of their own that likely serve as higher barrier of entries than what you describe (ie. requiring a phone number for verification or a small donation). Smaller email providers that don't bother with such anti-bot measures probably won't bother with the coin-holding approach either.
The approach is clearly targeted to these "anonymous" service providers like Disroot. These companies/organizations wouldn't like to do phone number verification because of privacy reasons. And it shouldn't be difficult for them to implement a software service connecting to block explorers to verify the customer's compliance with the "don't move the coins for a month" rule. Ideally an open source solution for that purpose would be created.
Quote
Additionally I'm under the impression that large scale spammers have long since transcended centralized email providers. Most seem to run email servers of their own, playing the anti-anti-spam-filter game at a wholly different level (eg. trying to circumvent their mail servers and domains from being blacklisted).
Yep, that may be true. This isn't a general anti-spam solution, but a solution for a subgroup of email and other social services like forums. (The "Copper membership" here at BCT inspired me a bit Wink )

Quote
Still, I think the coins would need to be actually at stake for this approach to be effective (eg. by keeping the coins in escrow or timelocked until a certain grace period).
Requiring a timelock in the transaction (via CLTV/CSV) is interesting, thanks for the suggestion!

I have also thought about an escrow approach (e.g. a contract where the customer can only move the coins after a month has passed, while the service provider can "confiscate" the coins if the customer malbehaves). But the drawback is that the service would need to run a Bitcoin node and take care for its security, which may be difficult for small e-mail providers or forums. It could be interesting though once such a service achieves a certain scale.
legendary
Activity: 3122
Merit: 2178
Playgram - The Telegram Casino
It's an interesting approach, but I'm also doubtful it would be all that effective.

Most large email providers already apply (centralized) anti-bot measures of their own that likely serve as higher barrier of entries than what you describe (ie. requiring a phone number for verification or a small donation). Smaller email providers that don't bother with such anti-bot measures probably won't bother with the coin-holding approach either.

Additionally I'm under the impression that large scale spammers have long since transcended centralized email providers. Most seem to run email servers of their own, playing the anti-anti-spam-filter game at a wholly different level (eg. trying to circumvent their mail servers and domains from being blacklisted).

Obviously the points above only consider email accounts. Other services may be a better fit for such a solution. Still, I think the coins would need to be actually at stake for this approach to be effective (eg. by keeping the coins in escrow or timelocked until a certain grace period).
legendary
Activity: 3906
Merit: 6249
Decentralization Maximalist
  • If the customer moves the funds before the deadline is reached, his account is automatically closed.

Once a user sends out his spam email, why would he/she care if you close the account?
He would have to move the Bitcoin funds before he can send emails. So he would have to do the "work" before he can benefit from the service.

He could create e.g. one account per day, moving the funds each day to another address and not caring about the account to be closed, but that would already reduce server load for the service, compared to situations where a spammer can open several accounts each day with throwaway email addresses and Captcha crowdworkers. If there are problems with customers following this kind of "attack approach" to open several spam accounts, such a kind of "transaction chain" could be detected, and the service could prohibit this kind of behavior. Also, the spammer would have to pay transaction fees each time he moves the coins.
Vod
legendary
Activity: 3668
Merit: 3010
Licking my boob since 1970
  • If the customer moves the funds before the deadline is reached, his account is automatically closed.

Once a user sends out his spam email, why would he/she care if you close the account?
legendary
Activity: 3906
Merit: 6249
Decentralization Maximalist
Currently, many web services which were offering cool and often free ("as in beer") things like anonymous E-mail accounts (e.g. Disroot, Teknik) are closing or restricting access, claiming problems with spammers.

I have thought about a very simple anti-spam solution for this kind of services that would not need any centralized third party and was completely Bitcoin-based. It's meant as an alternative to PoW-based concepts like Hashcash (it could be viewed as the "proof-of-stake version of Hashcash" Wink, even if the scope is not identical, as it's not meant for single e-mails).

The core idea is:
  • Require the customer to transfer a Bitcoin amount to an address he controls. The amount must stay on this address for an extended time until a deadline is reached (e.g. a month after registration). The service provider can require a timelock (CLTV) to ensure the coins are not moved. (Edited 10-2 based on HeRetiK's suggestion)
  • The customer must sign a message provided by the service provider to show he controls the address.
    Only one address per account on the service (e.g. 1 address per e-mail account)
  • If the customer moves the funds before the deadline is reached, his account is automatically closed.

This has the following effects and advantages (if we assume the "deadline" is one month after registration):
- The service can stay completely free, as the customer can move the funds to an own address.
- The service provider can always check that the customer is following the rules. He doesn't have to control Bitcoin funds, he does not even need a Bitcoin client as he can use block explorers.
- If the customer wants to create several accounts, he must move funds to different addresses and "freeze" them for a certain time. This makes it costly to create many accounts and adds volatility risk for the attacker.
- Alternatively he could create one address per month, but this is not enough to create massive spam accounts.
- For customers of "nerd-oriented" services like Disroot it shouldn't be complicated to move the Bitcoins and sign the message. Alternatively, a software for that purpose could be developed.
- Compared to a PoW-based protection, it's more complicated and also probably more costly to automate the process.

Thoughts?

It's only a pretty raw idea, and it's possible that it already was implemented or even is well-known already. If yes, then I would like a comment with a link to the implementation, as I would like to suggest this to Disroot and other services.
Jump to: