BitShares Core Release 2.0.180425 新版本发布

This is a bugfix release.

In this release we fixed a bug in account history plugin, which may result in incorrect operation history IDs being stored under certain circumtances. Account history is mainly used by 3rd-party businesses for integration.

This bug doesn't affect consensus or chain security.

Who need to upgrade, and what to do

Businesses (E.G. exchanges, payment processors, gateways or merchants) who're running witness_node with track-account option, if rely on correctness of operation history object IDs (1.11.x) returned by witness_node to identify transactions, are likely affected.

Please:

upgrade the node, and
restart the node with --replay-blockchain parameter, and
carefully check historical data which was retrieved from the old node and processed in the past, compare it to new data returned by upgraded node, deal with the differences if needed, and
perhaps review business data process logic.

Please be aware that the 3rd step is important for businesses to avoid processing same transaction (E.G. a deposit) more than once. After restarted with --replay-blockchain, history object IDs may have changed. For example, before restart, get_relative_account_history [account_name] 0 1 0 may return an operation history ID 1.11.123456789 which indicates a deposit, but after restart, operation history ID of the same deposit may have changed to 1.11.123456700.

All earlier versions are affected.

Who are not affected

Here are some cases likely not affected by the bug. However, for your own safety, please make decision by your own.

The bug doesn't affect delayed_node, so data stored and returned by delayed_node is always correct. IDs stored in witness_node can be different than those stored in delayed_node. If a business only reads data from delayed_node, it's not affected.
- However, if the business also reads data from witness_node, it can be affected.
Businesses that don't rely on correctness of 1.11.x IDs to identify transactions, for example those identify transactions by transaction IDs or signatures, are likely not affected, so don't need to upgrade.
Nodes that were not running with track-account option are not affected, so no need to upgrade.
- Nodes running with default options are in this categary.
- Public seed nodes, API nodes and witnesses should be in this categary.
Personal nodes that are not interested in history object IDs are probably affected, but usually don't need to upgrade.

More info about the bug

The bug was in account history plugin, if track-account option is used in a node, when forking occurs (E.G. due to network latency issues), the node may unintendedly skip some IDs. After that, incorrect IDs will be stored and then be returned when being queried. A restart with --replay-blockchain may correct IDs of existing/historical data, but doesn't prevent new incorrect IDs from being stored.

After upgraded and replayed, the node won't skip IDs, so will always store correct IDs.

BTS 2.0.180425 新版本已发布。这是一个BUG修复版本。

下载地址： https://github.com/bitshares/bitshares-core/releases/tag/2.0.180425

这个版本修复了一个账户历史插件的问题，该问题会导致某些情况下节点会记录错误的操作历史ID。主要影响第三方合作者进行系统对接。

这个问题不影响共识和安全。

谁需要更新，需要怎么做

交易所、网关、商户等第三方合作者，如果运行 witness_node 节点时使用了 track-account 参数，并且依赖于操作历史 ID （即 1.11.x）来唯一识别转账等交易记录，那么很可能已经受到这个BUG影响。

解决方法：

升级到新版本；
使用 --replay-blockchain 参数重启节点；
仔细检查以往处理过的操作历史记录，和升级后的节点返回的 ID 进行对比，如果需要，处理好其中的差异；
可能需要重新审查业务处理逻辑。

请注意，上面第3点很重要，其目的是为了防止同一笔交易（比如充值）被重复处理，导致损失。因为使用 --replay-blockchain 参数重启后，账户操作历史ID可能已经发生变化，比如，某一笔充值在升级前的 ID 是 1.11.123456789 ，升级后可能变成了 1.11.123456700 ，如果对接程序不能识别这两个ID其实对应的是同一笔交易，会导致重复入账，带来资金损失。

之前的版本都受到这个bug影响。

谁没有受影响

这里列出若干种可能没有受到bug影响的情形。但是，为了您的资金安全，请自行甄别确定是否受到影响。

这个bug不影响 delayed_node ，所以 delayed_node 返回的数据一直是准确的，虽然 delayed_node 连接到的 witness_node 数据可能不准确。如果对接程序只从 delayed_node 获取操作历史 ID，那么应该没有受到bug影响。
- 注意，如果对接程序也从 witness_node 读取数据，则可能受到bug影响
不依赖 1.11.x 这种ID来识别唯一交易的对接程序，比如按照交易的txID或者签名来识别的，不受这个bug影响。
没有使用 track-account 参数的节点不受这个BUG影响。
- 使用默认参数运行的节点不受影响
- 见证人、API节点、种子节点一般不会使用 track-account 参数，所以应该不受影响
个人节点可能会配置 track-account 参数，所以可能受到影响；但是，一般用户使用节点时，并不关心 1.11.x 这种操作历史ID，所以一般来说不用升级。

关于BUG的更多信息

如果使用了 track-account 参数，当网络发生分叉（常见的原因比如延迟），没升级的节点的账户历史插件会跳过一些操作ID，导致后续的操作ID都不正确。在使用 --replay-blockchain 参数重启后，账户历史插件内部的老数据的ID会被自动修正，但是新的数据ID还是可能出错。

升级后的节点不会再跳过ID，保证ID连续，所以不再会有这个问题。