而赎回证明超时通知，会被视为签名者中止的信号，这意味着签名者未满意系统要求，但系统不将其视为恶意。在赎回期间，这意味着系统无法验证赎回人是否收到了他们的资金。在这种环境下，系统会充公签名者的担保金，并将全部担保金作为赔偿发送给赎回者。采纳这种要领是为了防备以下环境：签名者在请求的赎回生意业务上生成签名，但又同谋在另一笔生意业务上生成签名，然后在确认正确的生意业务之前竞相确认其生意业务。
接下来要做什么？实际上，支持开放存款的担保金（以及部门未偿TBTC供给）完全属于一个单独的运营商，该运营商很早就插手了系统，在测试进程中，其与Keep团队常常保持相同。在暂停后不久，团队提出用1.005 BTC 兑1 TBTC的比率互换TBTC，以规复TBTC的供给，从而使该地点的供给规复了99.83％。团队会触发对开放存款的有节制赎回，以释放支持这些存款的剩余担保金。Keep团队还将协调排除系统中任何剩余的未利用ETH，尽量它们不存在风险。
2020年5月18日上午（UTC时间），在和主网举办了约莫48小时的测试之后，Keep团队抉择触发TBTCSystem合约答允的10天紧张存款暂停，该团队发明，当某些范例的比特币地点用于赎回时，存款合约的赎回流中呈现了一个重大问题，它会使开放存款的签名者担保金面对清算风险，因此抉择触发这一暂停。
（图片来自：tuchong.com）
系统确实很去中心化，关于问题的陈诉也写得很是具体； James Prestwich已在GitHub上宣布了一个PR，并提供了发起的修复措施。 在归并该修复措施之前，Keep团队会在接下来的几天举办测试。
在UTC时间5:18，Keep团队在确认问题的存在，并意识到合约无法简朴通过外部修复之后，抉择触发tBTC系统合约中可用的一次性10天紧张暂停。此成果可暂停为期10天的新存款，但不会影响任何已打开的存款。为了安详起见，触发任何tBTC系统更新的进程，需要钱包团队3名技能成员中的2名，通过手动的方法建设以太坊生意业务，然后利用气隙系统签署生意业务信息，最后将生意业务和签名提交到以太坊区块链。而该进程是在UTC时间5:45完成的。
而这一发起，也获得了Keep首创人的必定。
bytes memory _modifiedLegacyOutputScript =
(_output.slice(8, 3).concat(_output.extractHash()));
require(
keccak256(_modifiedLegacyOutputScript) ==
keccak256(abi.encodePacked(_d.redeemerOutputScript))
);
此代码等效于已陈设的代码。在意外修改旧版剧本之后，它会将它们与未修改的旧版输出剧本举办较量。当 _d.redeemerOutputScript是旧版剧本时，此等式将始终失败，而且生意业务将始终被还原。
最终，总结下这次事件傍边的几个问题：
——————————————————————————————————————————————————————————————————————
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
