区块链神吐槽原文标题：block 666833 处的分叉、RBF和“set in stone”
最近比特币BTC在区块666833出现了分叉，每个分叉各有一个区块。
分叉然后出现孤块其实在BTC网络中并不罕见，由于矿工之间的竞争大概1-2个星期就会发生一次。但是这次很巧的事情是两个相关的RBF（Replace-By-Fee）交易分别在两个分叉的区块中，所以有人认为这是双花攻击，并认为RBF不安全。另外，我又看到BSV支持者（微博@中本蒜-袁维）说BTC 0.1版本的协议就可以稳定不变，应该“set in stone”（一成不变的）。BCHer和BSVer也一直诟病RBF交易是 Core 引入的不安全机制。
搞清楚这些问题，首先要了解的是RBF交易的历史。
RBF的基础是 Transaction replacement（交易替代），BTC交易的每个input有个域sequence（顺序），如果矿工在打包交易的时候，发现两个交易使用了同一个input（即花掉同一个UTXO），那么sequence更大的交易可以替换掉sequence小的交易。Transaction replacement 在BTC的第一个版本就有了，也就是中本聪亲自设计了交易替换机制。中本聪原来的意图已经不可考了，只能猜测祖师爷希望给没有确认的交易一个反悔的机会。
但是 Transaction replacement 会带来一个比较严重的拒绝服务 bug，即攻击者可以不断向矿工发送这种替换交易，影响矿工的打包过程，矿工会不断的改变准备打包的区块中的交易，最后影响出块速度，而攻击者的攻击成本几乎为0。所以中本聪在2011年又自己 disable （禁用）了这个特性。
到了2015年，BTC的交易出现拥堵后，大家才发现 Transaction replacement 其实是很有用的：如果交易费太低，交易被卡在矿工的内存池的时候可以用一笔更高交易费的交易替换掉原来的交易，这种方式比矿工的加速器更加透明和廉价。
所以到了2016年 Peter Todd 设计的 Opt-in RBF 重新加入到了BTC源代码中，为了防止原来的拒绝服务攻击，Peter Todd加了两个限制条件：
- 替换的交易必须显式的申明自己可以被替换（sequence < MAX-1）。
- 替换交易的交易费一定要大于被替换交易，而且要支付一定的网络费用。这样就杜绝了拒绝服务的可能性。
具有讽刺意味的是 Peter Todd 因为设计 Opt-in RBF 遭到了BCH和BSV支持者大量的攻击，认为改变了中本聪的设计。我就觉得特别奇怪，明明Peter Todd是改进和完善了中本聪原来的设计啊。BSV支持者总说要把0.1版本的协议 set in stone，你把Transaction replacement重新引入回去试试？
比特币 区块block 666833 的分叉
回到区块block 666833处的分叉，看到好几个人都说0确认不安全，所以RBF只要不是0确认就是安全的。其实这次分叉两个RBF交易都进入了区块，并不是0确认，而且确实有可能双花。但是仔细分析，这种双花的可能性其实是很难站住脚的：
- 两个冲突的RBF交易进入两个分叉是概率非常低的情况，攻击者一般很难找到这种机会。而且究竟是哪个分叉获胜是随机的，所以即便攻击者找到这种机会，怎么获利也是一个很困难的问题。如果掌握强大算力的矿工要进行双花攻击，那跟交易是不是 RBF交易 完全没有关系，结论是 RBF 并没有增加双花的风险。
- 对于钱包或者交易所其实非常容易防止这种双花的可能性，只要是比特币全节点，就直接可以看到一个交易是否正在分叉上，然后推迟确认这个交易。由于矿工之间存在高速通讯协议，一般是3个区块分叉就会结束，所以最多等三个区块，这种双花可能性就消除掉了。
- Bitcoiner反复强调全节点的重要性，不仅仅是让静态的账本多几个拷贝，还可以让更多人更容易观察到账本的动态变化，审核异常情况的出现，这绝对不是相信几个矿工就可以替代的。
@废X废：划一条重点结论：“RBF并没有增加双花的风险”。0确认交易不够安全和有没有RBF并没有直接关系，RBF只是把替换交易的权力下放给了一般用户而已，矿池主动替换交易并不需要RBF。
玛雅cndx：谢谢，币知识增多。之前只知道中本聪最开始提出和支持RBF，后来由Core改进落地了新Opt-in可选择RBF。现知背后原因了。中本聪很有先见之明，知道将来会交易满会有需要增加手续费的情况，才设计RBF，也侧面说明其支持小区块软扩路线。只是当时尚未解决拒绝服务攻击，才暂时禁用。
推荐阅读