比特币的共识规则现正有一项软分叉进行中，虽然一切看起来均运作正常，矿工和矿池负责人绝对不能忽视以下的重要资讯和工作清单。
矿工和矿池负责人如有任何疑问，欢迎和我们联络。
摘要
你必须在区块419328号产出以前，检查你的所有节点，确保皆已升级至 Bitcoin Core 0.12.1 或相容软件。
如果你正在手动设定区块版本号，或正使用 coinbase 交易内的 nSequence 或 nLockTime 参数，你必须小心跟从以下指引。
“CSV” 软分叉已经达到「锁定」的要求，将会正式启动。在415296至417311号一共2016个区块之中，1946个(96.53%)显示已准备实施BIP68, BIP112 和 BIP113 (“CSV”) 软分叉。从417312号区块(2016-06-21 05:18:58 UTC)开始，CSV 软分叉进入为时约两星期的「锁定」宽限期，直至419327号区块。之后，BIP68, BIP112 和 BIP113的新规则便会正式实施。该软分叉 已过了临界点，如非有极大规模的区块链回滚，其实施已不可逆转。
在宽限期内，所有矿工必须升级至 Bitcoin Core 0.12.1 或任何支持 CSV 软分叉的相容软件。实际上，在编写本文的时间，Bitcoin Core 0.12.1 是唯一支持 CSV 软分叉的版本。矿工必须再三确认所有负责挖矿的节点以及备用节用皆已升级。
不依从以上指引者可能会产出无效区块，或会延长无效的区块链，造成区块链分叉，令有关矿工和广大比特币使用者蒙受经济损失。
Bitcoin Core 的默认设定会自动按BIP9的要求设定区块版本，然而我们留意到有些矿工会手动设定区块版本号，我们强烈建议不要手动设定区块版本号，因为这会对比特币系统带来风险。
如果有矿工设定了一个版本编号，却没有实施对应的规则，便可能会产出无效区块，并会延长无效的区块链。简单而言，不使用由 bitcoind 提供的默认版本值，可能会令版本编号与实际运作的规则不相符。
和BIP33/66/65所使用的 IsSuperMajority 软分叉不同，在 BIP9 的设计中，没有区块会因为不当版本号而被视作无效（根据 BIP65，最低有效版本号为4）。因此，矿工并无诱因去手动设定区块版本号，因为这只会带来不必要的维护工作与人为出错的风险。
然而，如果你并不依从以上建议，仍然是手动设定区块版本号，你必须作出以下行动。在「锁定」宽限期内，你必须去除 CSV 的版本号位元，即0号位元。例如，如果你本来的版本号是 0×20000001，你就必须在419328号区块前改变为 0×20000000，否则你将会令所有支持 BIP9 的节点的日志出现「未知软分叉」的警告讯息。详情请看Version Bits FAQ。
如果你不依从以上指引，你可能会令所有支持BIP9的节点收到升级警报，将会造成很大混乱。
至于让bitcoind自行设定区块版本号的矿工则无需采取任何行动。请留意，你的节点在419328号区块之前，仍然会产出0×20000001版本号的区块，之后0号位元便会自动被去除。
有些矿工可能会用 Coinbase 交易内的 nSequence 参数作为挖矿乱数。在 BIP68 生效之后，这些矿工需要加倍留意。
矿工如以任何形式改动 Coinbase 交易的 nSequence 参数，他们必须肯定 Coinbase 交易的 nVersion 参数 (不是区块版本号) 必须为1或以下，例如把 nVersion 参数硬性地手动设定为1。不依从以上指引者可能会产出无效区块，造成区块链分叉，令有关矿工和广大比特币使用者蒙受经济损失。
使用 bitcoind 提供的默认 Coinbase 交易 nSequence 和 nVersion 值的矿工无需采取任何行动。
这是比较罕见的情况，因为 Stratum 协议并不支持使用 nLockTime 参数作为挖矿乱数。然而任何这样做的矿工必须留意 BIP113 的新规则。
矿工如以任何形式改动 Coinbase 交易的 nLockTime 参数，他们必须肯定参数值如被视作 UNIX 时间戳(即大或等于500000000)，必须小于过去11个区块时间戳的中位数，除非 Coinbase 交易的 nSequence 参数同时为 0xffffffff。不依从以上指引者可能会产出无效区块，造成区块链分叉，令有关矿工和广大比特币使用者蒙受经济损失。
使用 bitcoind 提供的默认 Coinbase 交易 nLockTime 值的矿工无需采取任何行动。
声明：此文出于传递更多信息之目的，并不意味着赞同其观点或证实其描述。本网站所提供的信息，只供参考之用。
