YihaoPeng

不及时的回复：你看看 kafka broker 是不是抛出了什么异常。

在不修改区块链共识规则的情况下，没有办法阻止不可信矿工进行藏块攻击，因为： * 矿工完全知道他挖到的块是否符合爆块条件。即使某些链在挖掘时不发送网络难度（比如以太坊），也可以去区块浏览器查询。 * 不提交爆块对矿工来说没有明显损失，他只是损失了一个share而已。 * 矿池无法证明矿工没有提交爆块是因为他藏块攻击，在短时间内，“藏块攻击”和“运气差没挖到”无法区分。 所以，藏块攻击基本上只能进行事后检测。根据一段时间用户提交的share的实际难度分布来观察他是否有藏块攻击的倾向（比如，高难度share的数量明显小于正常水平），或者观察到用户使用了不常见的代理程序（通常用户不会直接修改矿机固件，都是用代理做的藏块操作）。目前sserver已经开始在share中记录`bits_reached`，这是share实际hash达到的难度目标（不是任务难度），所以可以用来观测矿机的提交难度分布。 用这个工具程序 https://github.com/btccom/btcpool/tree/master/tools/sharelog_to_parquet 可以把sharelog转换为可供大数据分析程序(比如Apache Spark)使用的parquet格式，这样就可以用数据分析工具绘制难度分布图表了。这个程序会把bits（hash target的压缩）转换为浮点型的difficulty（难度数值），方便直接进行比较运算。bits具有内部结构，无法直接进行大小比较。

我看bitcoind RPC `getblockchaininfo`会返回`difficulty`，所以你应该可以据此找出它是如何计算的。

应该是写错了，我会改成 `RD_KAFKA_OFFSET_TAIL(1)`

已经尝试在 https://github.com/btccom/btcpool/commit/f312ceb304caeae40cb94b6932b5216375e748bd 中修复

如果采用受影响的版本，jobmaker重启的时候应该需要很多时间。 受影响的版本：从 2019-07-17（ 34094cb9e04608b0d39c0a2f33b5f9f207ffd5d1 ）至今。 偏移`1`应该会导致重头消费所有相关topic，导致 jobmaker 重启后需要大量时间才能开始发送新任务。 所以要注意，如果需要重启 jobmaker，应该注意它是否发送 job。如果发送不及时，应该升级到修复该问题的版本。

如果node不存在，就无法watch。所以目前的顺序是正确的。 不过，sserver本身不负责创建子账户，需要运行开启自动注册的`userChainAPIServer`模块。如果没有该模块，则sserver不会有后续动作。 https://github.com/btccom/btcpool-go-modules/blob/d2b1edc5bde154e9d9821ef79e253f7efff53eff/userChainAPIServer/config.default.json#L11

需要对配置和提交进行检查才能知道发生了什么。我亲测是可以接受的。

问题长时间没有人回答，等待关闭。。。

希望有人来回答 目前 mergedMiningProxy 支持写入数据库，但是文档缺失，建表语句也找不到。