http://www.7klian.com

BCH 硬分叉背后:一场预谋已久的真实进攻

进攻导致了矿工节点无法打包,BCH 方面通过雷同于空块进攻的方法,紧张挖出十个空块以触发转动查抄点担保进级。进攻产生约 1 小时后,BCH 矿池上线紧张修复后的代码乐成继承出块。

4c83ab55623633c86ec711b3d68ccdea506b228178ff1533f287ab744b006c44

然而在组块时为什么没有拒绝这个 TX 呢?我们可以在 Bitcoin-ABC 的补丁中发明眉目。

5 月 15 日 BCH 进级遭到进攻,慢雾安详团队实时跟进,并在社区里留意到相关阐明事情,通过交换将此阐明文完整转载于此。这是一场真实进攻,从行为上阐明来看确实预谋已久,但 BCH 响应很实时,乐成化解了一场安详危机。

总结

进攻者操作了 BCH 引入 OP_CHECKDATASIG 时发生的,又未完全修复的裂痕,巧妙地结构了进攻载荷。进攻者应该高度相识客户端代码,并熟悉 OP_CHECKDATASIG 裂痕。

其内容为

相关代码位置:

即,,单个 Transaction 中 SigOP 的数量不能高出 20000。

OP_CHECKDATASIG OP_CHECKDATASIG OP_CHECKDATASIG OP_CHECKDATASIG

OP_CHECKDATASIG OP_CHECKDATASIG OP_CHECKDATASIG OP_CHECKDATASIG

BCH 的 5 月 15 日 进级遭到进攻,导致节点报出 too many sigops 错误。经阐明,进攻载荷为一个准确结构的 P2SH Transaction,操作了 BCH 去年 11 月进级引入的 OP_CHECKDATASIG 操纵码。

因此,进攻载荷会在矿工组块的时候被包括进区块中,然而,由于其他代码正确地统计了 SigOP,节点会拒绝该区块,这导致了 BCH 无法出块。

不外同时也有人调查到,在 582698 区块高度,有矿工挖出了哈希末了为 6bf418af 的区块,巨细 139369 字节。但随后该区块被 10 分钟后 BTC.top 挖出的哈希末了为 449e2bb4 区块所重组。或者是一次误伤,不外可见 BCH 对付进级防守之严密。

可见个中包括 15 个 OP_CHECKDATASIG

裂痕道理

细心的话,你已经发明白,进攻载荷的 SigOP 数量为 1334*15 = 20010,这个进攻载荷 TX 会被节点拒绝,报错等于 too many sigops,这是导致节点拒绝包括该 TX 的区块的原因。

OP_CHECKDATASIG OP_CHECKDATASIG OP_CHECKDATASIG OP_14 OP_CHECKDATASIG OP_ENDIF

这两个符号有什么区别呢?

作者:刘一鸣

OP_TRUE

所以我们可以见到,当仅利用了 STANDARD_SCRIPT_VERIFY_FLAGS 时,计较剧本中 SigOP 数量时,是不包括 OP_CHECKDATASIG 的。所以这个包括 20010 个 SigOP 的进攻载荷,在组块时,统计出来的 SigOP 数量为零。

进攻道理阐明进攻载荷

捕获到的进攻载荷 TXID 为

该进攻载荷由 1334 个 Input 组成,每一个 Input 均是 P2SH 名目。

OP_FALSE OP_IF OP_CHECKDATASIG OP_CHECKDATASIG OP_CHECKDATASIG

该进攻载荷操作了一个 CORE 曾经帮 ABC 修复,但未完全修复的裂痕,制造了组块和验证之间的差别,从而导致矿工组出的区块不被节点接管。

if (nSigOpsCount > nMaxSigOpsCount) { return state.DoS(100, error("ConnectBlock(): too many sigops"), REJECT_INVALID, "bad-blk-sigops");}

相关代码位置:

static const uint32_t STANDARD_CHECKDATASIG_VERIFY_FLAGS = STANDARD_SCRIPT_VERIFY_FLAGS | SCRIPT_ENABLE_CHECKDATASIG;

在 policy 中我们可以找到他们。

裂痕配景

OP_CHECKDATASIG 是一种椭圆曲线签名校验指令 (SigOP),这类指令由于需要举办椭圆曲线运算,执行开销远高于其他指令。因此在节点代码中,对付这类指令的数量做出了限制,以制止拒绝处事进攻。

相关代码位置:

补丁位置:https://reviews.bitcoinabc.org/D3053

文章来历:公家号 慢雾科技

地址的函数为:AcceptToMemoryPoolWorker

可见原代码组块进程中在计较 Transaction 中的 SigOP 数量时,错误地利用了 STANDARD_SCRIPT_VERIFY_FLAGS,而非 STANDARD_CHECKDATASIG_VERIFY_FLAGS。

static const uint64_t MAX_TX_SIGOPS_COUNT = 20000;

原文标题:《BCH 进级进攻事件安详阐明》

// 原代码 int64_t nSigOpsCount = GetTransactionSigOpCount(tx, view, STANDARD_SCRIPT_VERIFY_FLAGS); // 补丁代码 int64_t nSigOpsCount = GetTransactionSigOpCount(tx, view, STANDARD_CHECKDATASIG_VERIFY_FLAGS);

相关代码位置

郑重声明:本文版权归原作者所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们修改或删除,多谢。

说点什么吧
  • 全部评论(0
    还没有评论,快来抢沙发吧!