StratumServerBitcoin.cc里面checkshare处理是不是有的地方少判断？

[rocqina]

if (sjob->proxyJobDifficulty_ == 0 && (bnBlockHash >> 10) <= bnNetworkTarget) { 这地方是不是应该需要判断StratumStatus::UNKNOWN == shareStatusReturn 还有下面辅币爆块的判断

[YihaoPeng]

即使任务在主链stale，但只要达到难度要求，也可以在联合挖矿币种爆块。因为联合挖矿只是共享了主链的区块头数据结构，与区块在主链上的状态完全没有关系。

我们之前的代码在主链stale的时候就完全不进行后续检查了，这就使部分share失去了在联合挖矿币种爆块的机会，使后者的幸运值达不到100%

目前的代码修复了这个问题，可以在主链任务stale时让联合挖矿币种正常爆块，所以我认为不判断是正确的。

[rocqina]

明白，但是会不会出现这种情况，短时间内大量的stale任务过来，恰好能够辅币爆块，造成短时间大量提交辅币爆块请求

[SwimmingTiger]

stale share并不会比正常share的爆块几率高（你是没有办法刻意伪造能达到联合挖矿币种要求难度的提交的，除非你真的恰好算了出来）。所以只要辅币的难度够高（比如Namecoin，挖矿难度接近于Bitcoin），这种情况就不会发生。此外，如果你挖的联合挖矿币种爆块难度很低（比如RSK），正常提交爆块的概率和stale share爆块的概率是一样的。目前因为没有“联合挖矿stale”状态，只能全部提交。

如果要改进，只能添加“联合挖矿stale”状态，不过对于Namecoin、Dogecoin这样的币种，还需要考虑在一个AuxPowHash里“同时包含好几个辅币的挖矿任务”的情况（因为确实可以，我们的程序也支持，参考 mergedMiningProxy），这些币种具有各自的stale状态，要正确实现难度更为复杂。

然而，我们实现stale是为了正确计算主链收益，而不是为了阻止爆块提交。鉴于爆块提交始终是小概率事件，我不认为需要专门花精力去实现提交抑制逻辑，因为如果实现的不完善导致不能爆块，会有更大的损失。并且大部分联合挖矿币种的难度都足够高，客户端也足够健壮，即使多提交几个不能爆块的请求也不会有什么事。