我的理解是未成交的。“所有的”是什么

“所有的”是指已成交的、未成交的、取消的这三种状态的订单。目前看 btsbots 的代码，我觉得 1.4.x, 1.7.x, 1.8.x 应该是代表的未成交的订单。由于没有看过 core 的代码，这里不确定已成交的订单和取消的订单是否还会占用 1.4.x, 1.7.x, 1.8.x。

btsbots 有个持仓排行榜功能，是按资产分类后的余额+挂单金额的合计来排的，所以 2.5.x + 1.x.x 可能是为了这个用途？

目前 btsbots 的代码逻辑是：如果从网络上同步了一张用 10 bitCNY 买 11 BTS 的订单，那么就在数据库里把这个人的 bitCNY 的 balance 剪掉 10，同时 BTS 的 balance 加 11。但是目前 2.5.x 是已经刨除完挂单的数据，再这么操作一遍岂不是重复了，所以没看明白 btsbots 的逻辑。难道说在这套代码最后一次修改之前，2.5.x 返回的是没有刨除挂单金额的？

节点同步状态判断，这个应该有吧？如果网络出现问题，比如在线率太低，头块时间太久，机器人应该临时停工的。

这个在前端下单的时候，印象中是会比对下当前数据库的最高位和线上实际的最高位，如果超出一个阈值（印象中是小于3的一个值），就不会下单了。

• 分叉的处理。当出现小分叉时，节点推出来的1.11.x数据会被回滚，但回滚是没有推送消息的；切换分叉后，会有新的一批同样id的1.11.x推出来。
• 节点同一个块推送多次消息的bug处理。因为多线程原因，节点可能会同时从p2p网络多次收到同一个块，所以会处理多次，虽然后续的块不会对节点内部状态造成影响，但可能有多次消息推送的问题（我不太确定）

关于这些，我暂时还没有看到 btsbots 是怎么处理的，接下来读代码的时候，会留一下这几种情况。