5x,6p 都能靠这招解决 boot loop to death 的问题。

@rockyou12 因果关系你没搞清楚啊。是为了慢才选择反推，还是因为选择了这种加密所以才慢。如果我不需要用这么慢，我是不是就不需要用这种加密了。

@rockyou12 更准确的讲是算的比新记录产生的慢。如果增加新记录的频率很高，对单个记录的消耗要求也就不用那么高了。比方讲做个网络游戏，一秒钟 N 条记录，为了防作弊，用区块链来存。直接套在别的领域现在是没什么意义，但是改动一下，配合其他现有的方法，想象空间还是很大的。

在我看来，比特币的区块链安全，因为两点：1.它不存当前的状态，而是存历史记录。产生新的记录时，会用旧的记录来验证合法性。2.因为历史记录前后有关联，改一个就得改后面全部的。但是创建一个的时间非常久，消耗的资源非常大，而新记录又在不断增加，所以改起来几乎不可能。
想把这个模式往其他地方套，就得想办法解决：1.怎么用旧的记录来验证新记录。2.如果新记录产生的频率不高，如果不能接受“得算很久才能创建一个记录”，怎么让改旧记录的行为得不偿失。
这东西已经扩宽人的思路了，现在没什么应用不代表以后没有。

@tscat
粗略的想法：如果我们现在认为一个文件上下载的节点越多，那么这个文件就越流行。这时候要获取最多的下载币，矿工必须有足够多的节点来跟整个网络竞争，如果创造下载币时，每天的数量是有上限的。哪怕他获得了最多，因为有上线，收益不会比他的付出多。这样应该能限制作弊吧。

@gy911201
之所以说受比特币启发，并不是说这个币是在区块链上生成的。而是说 P2P 下载的网络类似于区块链，维护这个网络的人应该收到奖励。没有下载软件，这个网络没法运作。所以软件提供者也是维护这个网络的一员，所以他们也应该收到奖励。而奖励提供者就是那些想下载的人。
后面所提到的区块链，说的是当这个网络存在有利益交易了，那么我们得保证没有人能凭空创造出很多货币出来，交易的过程是不被伪造的。所以交易记录应该保存在安全的地方，例如区块链上。它是 Q 币，但是不被腾讯（软件商）控制。

@tscat
如果我们把获取方式改成与资源流行度有关，大矿工不能自己跟自己玩。他们还是得分享跟真正要下载的人。例如一个热门资源出来了，大矿工立马下载好，并且全速上传。那么对于下载者来讲，他还是用高速下载到了东西。这种情况下，这个网络是健康的吗？


@msg7086
仅仅是讨论。想法可以扩展到 cdn 或者有其他下载行为的软件上面。假设 steam 推出一种币，帮助上传资源的人可以获得。steam 把游戏价钱里头用来部署 cdn 的钱砍掉。这部分钱需要用币换。这时候，币是已经有游戏的人跟想要买游戏的人之间的交易。算到底，steam 说不定还能省了钱。

@gy911201
@tscat
@ilylx2008
要得到好答案必须得有好问题。我觉得“刷”从根本上不是作弊问题，而是如何衡量虚拟货币价值的问题。
下载币变多了，愿意消费下载币的人未必变多，作为软件商，我提供的增值服务必然要涨价。作为准备购买下载币的人消费增值服务的人，我自然不愿意花高价去买下载币。这样的情况下，是否最终会形成一个平衡的状态呢？
如果学习比特币，下载币的获取难度是逐渐增加的，那初期可能会有人刷币屯币，这时候又会造成怎样的影响？
如果在这个网络里的所有人都努力上传，而增值服务只有离线下载这一种类型，那么自然就不会有人需要增值服务。下载币的价值就会下降。价值下降，未必就又有那么多人上传了，那么是否最终又会变成一个平衡状态呢？
我相信不仅是我这个虚构的下载币，比特币，其他虚拟货币应该都有这些问题。

同样的 HTML 页面，app 里打开卡成狗，浏览器打开没毛病。所以这是为什么呢？
同样的 HTML 页面，app 让打开，浏览器打开之后给我弹个窗，让我去下载 app。这又是为什么呢？

原图手机里打开，找你们设计过来，问他这字小不小。他要是说不小，就这么设计的，那就是这么设计的。

http://jsbin.com/jotarociwa/edit?html,js,console,output
就是递归，你感受一下异步和同步的区别。

因为你们收到的简历多 + 1。
真招不到人了，上门递信封的人都得看看。

你的产品里有大量 ajax 渲染的内容吗？如果有，那么一个前端模板引擎可以帮你省掉很多事，减少很多 bug。
你的产品里有大量“一个操作，多个地方的显示内容需要跟着变化”的功能吗？如果有，那么把这种操作抽象成 mvc，可以省掉你很多事，减少很多 bug。
你的产品里需要“无刷新”的体验吗？如果有，那么你需要砍掉后端渲染的页面，在前端控制路由和渲染。
你的产品里有很多重复的功能，而且它们都可以封装成组件吗？如果有，那么你需要一个统一的封装组件的方法，一个统一的让组件间相互沟通的方式。
你的产品里 js 代码多吗？如果多，那么你需要一个统一的组织代码的方式。

如果你的产品里大都是就是点一个按钮，弹一个窗口，点一个链接，页面先成空白。那你什么都不需要。

tasker。内置 http 请求功能，还能写 js 的脚本。

苹果承认故意降频前：
“ iOS 不像安卓一样用了一两年就卡，我 xx 年买的 xx 还是丝般顺滑。”
“你的 iOS 卡是因为你没用 dfu 刷机，刷完就不卡了。”
“我的 iOS 上个版本有点小卡，现在又是很流畅了。”

苹果承认故意降频后：
“给用户提示不是苹果的风格。乔布斯说过用户都是 sb，不知道自己要什么。所以背地里降频很合理。”
“不卡就会自动关机，我宁愿卡点好。”
“ xxx 电压供不起 xxx 频率的 cpu... 降频非常合理。” 大家都是硬件专家。

苹果电池降价：
“老机子又能重生了！太棒了。”

洗来洗去明年出新的 iOS 之后，卡的也不是安卓。跟这种给人卖了还帮着数钱的人有什么好辩的。

一块电池四五百次的充电寿命吧。如果苹果百分之八十损耗就开始降频，那一块新电池顶多也就充个一百次又要换。你一天几充？买便宜的还是买贵的心里有数了吧。

到底性能下降是不是因为电池损耗，去找个新机子升级试下不就行了。

工期紧，任务重，中途又随意变化需求，代码里增添了很多 quick fix，workaround。
赶完进度之后只会觉得“啊，总算搞定这破东西了，再也不想碰了。”