实际上，到底是分叉，还是较少算力方妥协，根本没有人知道。在事情没有真正发生之前，所有的一切都是猜测。
现在分叉规则是，最近 1000 个块中有 750 个标注 Classic ，就开始执行分叉。我的问题是一定需要掌握 75% 的算力才能分叉吗？低算力是否可以靠运气爆棚，达到分叉阈值呢？
于是，我做了下计算，老实说我的统计学学得很差。我一直等人计算，结果等了很久，没有人算，所以没办法，我只能自己动手，有错误请大家指出。
其实，这是个二项式概率分布问题。如果 Classic 掌握的算力比例为 p，那么它在最近 1000 个块中爆 750 个块的概率为：
X(750) = C(750, 1000) * P ^750 * (1-P) ^ 250
那么，它在最近 1000 个块中爆 >= 750 个块的概率是：
X = X(750) + X(751) + X (752) + ……. + X (1000)
于是，我分别对阈值 950, 900, 750, 500 做了计算，结果见下表。
这 个表的意思是，如果阈值是950个块，那么掌握95%的算力，将有53.75%的成功概率，这个概率很高，基本上铁定会成功。如果掌握94%的算力，也有 10.06%的概率成功，经过一段时间也肯定会成功。如果我们认为万分之一才代表万无一失。那么，算力小于 91.94% 的话，就基本不可能成功了。
同理，如果阈值是900个块，算力小于86.04% 就不可能成功了。如果阈值是750个块，算力小于69.64% 就不可能成功了。如果阈值是 500个块，算力小于44.10%就不可能成功了。
有没有发现什么呢？是的，阈值越高，运气成分越小。如果阈值是950个块，必须达到92%的算力才有可能靠运气蒙。如果阈值是750个块，只要算力70% 就可以依靠运气去蒙，哪天运气爆棚，说不定就成功逆袭了。
不要觉得运气因素不重要。大家还记得前段时间突然在 4 小时内爆 48 个块吗？有人计算说是几十年才能一遇。
以上我只列结果，不想下结论。每个人都有自己的解释，也有人根本不在乎70% 算力就分叉，所以多说也无益。
最后，我想说说，我为什么做这件事情。
做任何事情都有风险，但是我们总是可以通过一些计算，或者一些模拟去降低风险。如果你真的想推进扩容，就去做一些力所能及的事情，让大家对各种风险越来越明确。
我不得不说， Classic 是非常不负责任的。为什么？当一件事情的后果不明确的时候，如果你一定要推进它，那么你就得对这件事情的风险进行评估。
如 何评估呢？其实工程上有很多手段。比如：建立一个类似的网络（如：某山寨币），呼吁大家一起建立节点，并做分叉实验，随机选择一定比例的节点拒绝更新，另 外一些节点更新，看看什么情况下会分叉，什么情况下不会分叉，以及通过分析，建立一些可行的机制或者流程，把分叉风险降到最低。如果你觉得真实实验成本太 高，或者不容易实现，你也可以在计算机上做仿真模拟实验，看看到底会发生什么情况。实验做完之后，发布完整的实验报告，以及各种风险的评估，包括概率和后 果。这样做才是负责任的态度。
不是说有风险的事情就不能做，而是说你要尽可能对风险进行评估，并且将风险降到最低。不是简简单单一句“较少算力的一方会妥协”就完事了，然后开始没完没了的撕逼，我倒是想支持你，可惜我说服不了自己。
反 过来， Core 推行的 SW 方案，已经在 test-net 上开始测试，这就是负责任的态度，无论这个测试花多长时间，无论测试过程中发现多 少 bug ，都是负责的表现。因为测试时间越长，测试得越仔细，我们才越有把握。所谓代码改动太大，根本不是反对 SW 的理由。很多软件在开发的过程 中都经历过推倒重写，只要新版本经历过足够仔细的测试，就没有问题。
不要再说什么扩容很急了，如果真着急，是不是早就应该去做模拟或者仿真实验了？我真的没有感觉到着急，真正着急的人不会什么测试都不做的。
至于政治上的事，我就问你，支持了 Classic 是不是就不独裁了？从加文的表现看，他会比 Core 更独裁。他独裁的时候，怎么不提花园论？他下台了，花园论就出来了，呵呵！
开发者干不了坏事的，客户端需要矿工和节点支持才能实施。如果矿工和节点拒绝支持，开发者狗屁都干不了。比特币的设计是完美的，开发者和矿工，谁也别想轻易改动网络，互相制衡。这种不能轻易被改变，才是我们用户敢拿它储值的根本。
来自：币科技
作者比特币感谢地址:1AHR999Dsz1J3it2XHjKJvWsMqRaTaBchm
注：本文观点仅代表作者，与本站无关
