这是一个创建于 3119 天前的主题，其中的信息可能已经有所发展或是发生改变。
有个思路不知是否可行
客户端（网页）需要运行一个耗时耗内存耗 cpu 的运算，得出的结果同刷屏结果一同 post 给服务器，服务器验证该结果符合某项特征（或预先算好并对应加载页面时的 request 或 openid 《微信》），符合特征则正常投票，不符合则发回客户端重新计算，直到计算正确为止。
这就要求该运算对非刷票用户来说没有影响，对刷票公司来说，则会耗尽对方的机器资源
以上是我的想法，不知道是否可行，如果有 V 友有更好的想法，欢迎提出来一起讨论。
另外，虽然有想法，但却不知道如何实现
 |
1
fcicq 2016-06-03 23:07:17 +08:00
hashcash 嘛. 发展到极致就是要求付费投票, 因为计算能力或者电费也是钱.
|
 |
2
ctsed 2016-06-03 23:56:09 +08:00
ty 以前想到过
|
 |
3
gdtv 2016-06-04 00:04:31 +08:00
没有什么是钱不能解决的
|
 |
4
just4test 2016-06-04 00:10:29 +08:00
这是拿你自己算力和攻击者的算力对烧啊。
|
|
5
just4test 2016-06-04 00:15:34 +08:00  1
我觉得可以不实时显示票数，这样刷票者就不能真正确定刷票是否有效。然后每过一个长周期结算，并排除所有可疑的投票。
最好还是付费投票，短信一块钱一条。想刷就刷呗。 |
 |
6
peter999 2016-06-04 00:17:59 +08:00
可以利用凌晨的闲时资源，先算好大量结果存入队列，投票的时候再发给前端。
|
 |
7
soland 2016-06-04 00:20:25 +08:00
是个好想法。
不同于通常的付费投票或是算力对烧。 可以不对等加密，使客户端的计算量远远大于。 |
 |
8
shiny 2016-06-04 00:21:53 +08:00
如果刷票的经济利益大于计算开销，还是防不住的。
|
 |
9
kkgogo 2016-06-04 00:26:52 +08:00
别着急，也许有两年这些就不是问题了，比如读取芝麻信用……
|
 |
10
billlee 2016-06-04 00:30:25 +08:00 1
@just4test 双方付出的算力不一样，一般是要求请求方通过附加一个数，使得算出的 hash 符合指定特征（比如低 n 位全为 0 ）。这样请求方要暴力尝试约 2^(n-1) 次 hash, 验证方只要算一次 hash 就可以了。
|
 |
11
XianZaiZhuCe 2016-06-04 04:27:56 +08:00
@just4test 不实时显示票数 + 1
|
 |
12
lecher 2016-06-04 05:15:10 +08:00 via Android 1
没有考虑过用户体验吗，一个普通用户投次票还要计算一段时间，活动流失率高了谁背锅。不是什么网站都有 12306 的用户刚需。
在对抗刷票这个事情上面，增加刷票成本确实是最合适的办法，这个方法在单次投票期望收益低于一毛钱的时候可以对抗。 通常单机 http 代理池做刷量的是一分钱一个的刷票。 到一毛一次的期望收益，就可以上虚拟机多开脚本批量刷了。 到一块钱一次的期望收益，投票抽奖之类的奖品，就等着被真机批量刷吧。 我知道像几块钱一次的应用活跃度刷量，淘宝刷单之类的。你要求一个手动操作流程耗时十分钟都有一票人不停刷。 只要收益足够，上僵尸网络也有人玩得起的。 类似的点子我记得 v2 有人的博客做过这样的计算，不过出发点是做防刷的，有效肯定是有效，浏览器的 js 那个渣性能，拖垮客户端都没问题。但是 js 是没法混淆代码的，除非期望收益低，不然把 js 代码一扒，转成 c 写的计算，照样刷你的接口。 |
|
13
ctsed 2016-06-07 12:13:38 +08:00
|
Select Language