对付刷票党的思路

[zanpen2000]

有个思路不知是否可行

客户端（网页）需要运行一个耗时耗内存耗 cpu 的运算，得出的结果同刷屏结果一同 post 给服务器，服务器验证该结果符合某项特征（或预先算好并对应加载页面时的 request 或 openid 《微信》），符合特征则正常投票，不符合则发回客户端重新计算，直到计算正确为止。

这就要求该运算对非刷票用户来说没有影响，对刷票公司来说，则会耗尽对方的机器资源

以上是我的想法，不知道是否可行，如果有 V 友有更好的想法，欢迎提出来一起讨论。

另外，虽然有想法，但却不知道如何实现

[fcicq]

hashcash 嘛. 发展到极致就是要求付费投票, 因为计算能力或者电费也是钱.

[ctsed]

ty 以前想到过

[gdtv]

没有什么是钱不能解决的

[just4test]

这是拿你自己算力和攻击者的算力对烧啊。

[just4test]

我觉得可以不实时显示票数，这样刷票者就不能真正确定刷票是否有效。然后每过一个长周期结算，并排除所有可疑的投票。

最好还是付费投票，短信一块钱一条。想刷就刷呗。

[peter999]

可以利用凌晨的闲时资源，先算好大量结果存入队列，投票的时候再发给前端。

[soland]

是个好想法。

不同于通常的付费投票或是算力对烧。
可以不对等加密，使客户端的计算量远远大于。

[shiny]

如果刷票的经济利益大于计算开销，还是防不住的。

[kkgogo]

别着急，也许有两年这些就不是问题了，比如读取芝麻信用……

[billlee]

@just4test 双方付出的算力不一样，一般是要求请求方通过附加一个数，使得算出的 hash 符合指定特征（比如低 n 位全为 0 ）。这样请求方要暴力尝试约 2^(n-1) 次 hash, 验证方只要算一次 hash 就可以了。

[XianZaiZhuCe]

@just4test 不实时显示票数 + 1

[lecher]

没有考虑过用户体验吗，一个普通用户投次票还要计算一段时间，活动流失率高了谁背锅。不是什么网站都有 12306 的用户刚需。

在对抗刷票这个事情上面，增加刷票成本确实是最合适的办法，这个方法在单次投票期望收益低于一毛钱的时候可以对抗。
通常单机 http 代理池做刷量的是一分钱一个的刷票。
到一毛一次的期望收益，就可以上虚拟机多开脚本批量刷了。
到一块钱一次的期望收益，投票抽奖之类的奖品，就等着被真机批量刷吧。

我知道像几块钱一次的应用活跃度刷量，淘宝刷单之类的。你要求一个手动操作流程耗时十分钟都有一票人不停刷。

只要收益足够，上僵尸网络也有人玩得起的。

类似的点子我记得 v2 有人的博客做过这样的计算，不过出发点是做防刷的，有效肯定是有效，浏览器的 js 那个渣性能，拖垮客户端都没问题。但是 js 是没法混淆代码的，除非期望收益低，不然把 js 代码一扒，转成 c 写的计算，照样刷你的接口。

[ctsed]

r#11 不实时显示票数不怕被人民群众唾沫淹死？
@just4test
@XianZaiZhuCe