Ну смотри что происходит:
1. Пул дает майнеру заголовок блока и говорит: нука давай ищи красивый хэш этой фигни.
2. Майнер находит хэш и посылает обратно пулу хэш вместе с заголовком который сам же пул ранее прислал (см. пункт 1)
3. Пул говорит: чувак, твой заголовок блока неправильный.
4. Переходим к пункту 1.
Как такое возможно? Пул ругается на данные, которые сам же ранее посылал.
Я не знаю, че там у вас за алгоритмы. Но если это просто форк биткоина без наворотов, то у меня только одна идея: пока майнер ищет хэш, кто-то находит хэш раньше и в пуле цепочка блоков становится выше, чем у майнера. Соответственно когда тормоз-майнер посылает решение, пул говорит, что твое решение уже устарело.
Еще могу посоветовать найти в исходниках строку "bad-cb-height" и заценить конкретно - когда ваш форк выплевывает эту ошибку.
Спасибо, а может быть проблема в том что мы сделали развилку на 2013 годе? И из-за разницы во времени блокчейна это и происходит или это неважно? И если из-за этого это можно исправить как-то? Но тогда почему сам кошель майнит нормально? Тут как бы смысл биткоины раздать бесплатно тем кого обманули в 2013 риптилойды сатанисты.
И вот еще может быть проблема из-за низкой сложности она сейчас всего чуть больше 1.315277164532573.
Если кошель майнит, значит проблема не в исходнике, а в пуле (его настройках). Может в настройках пула сложность слишком большая и майнер не успевает найти блок с такой сложностью? Может время на серваке с пулом корявое?
Попробуйте вот этим майнером локально на компе помайнить.
https://github.com/pooler/cpuminer/releasesтолько разберитесь с настройками.
Попробывал этот майнер тоже самое в пустую работает но этот ошибок просто не выводит а результат тотже самый.
Поискал в исходниках по ошибке вот что нашел. Что делать?
validation.cpp
// Enforce rule that the coinbase starts with serialized block height
Enforce rule that the coinbase starts with serialized block height
if (nHeight >= consensusParams.BIP34Height) {
CScript expect = CScript();
if (nHeight > FORK_BLOCK) {
expect << std::vector<unsigned char>(FORK_HASH_UINT256.begin(),
FORK_HASH_UINT256.end());
}
expect << nHeight;
if (block.vtx[0]->vin[0].scriptSig.size() < expect.size() ||
!std::equal(expect.begin(), expect.end(),
block.vtx[0]->vin[0].scriptSig.begin())) {
return state.DoS(100, false, REJECT_INVALID, "bad-cb-height", false,
"block height mismatch in coinbase");
}
net_processing.cpp
} else if (status == READ_STATUS_FAILED) {
// Might have collided, fall back to getdata now
std::vector<CInv> invs;
invs.push_back(CInv(MSG_BLOCK | GetFetchFlags(pfrom), resp.blockhash));
connman->PushMessage(pfrom, msgMaker.Make(NetMsgType::GETDATA, invs));
} else {
// Block is either okay, or possibly we received
// READ_STATUS_CHECKBLOCK_FAILED.
// Note that CheckBlock can only fail for one of a few reasons:
// 1. bad-proof-of-work (impossible here, because we've already
// accepted the header)
// 2. merkleroot doesn't match the transactions given (already
// caught in FillBlock with READ_STATUS_FAILED, so
// impossible here)
// 3. the block is otherwise invalid (eg invalid coinbase,
// block is too big, too many legacy sigops, etc).
// So if CheckBlock failed, #3 is the only possibility.
// Under BIP 152, we don't DoS-ban unless proof of work is
// invalid (we don't require all the stateless checks to have
// been run). This is handled below, so just treat this as
// though the block was successfully read, and rely on the
// handling in ProcessNewBlock to ensure the block index is
// updated, reject messages go out, etc.
MarkBlockAsReceived(resp.blockhash); // it is now an empty pointer
fBlockRead = true;
// mapBlockSource is only used for sending reject messages and DoS
// scores,
// so the race between here and cs_main in ProcessNewBlock is fine.
// BIP 152 permits peers to relay compact blocks after validating
// the header only; we should not punish peers if the block turns
// out to be invalid.
mapBlockSource.emplace(resp.blockhash,
std::make_pair(pfrom->GetId(), false));
}
} // Don't hold cs_main when we call into ProcessNewBlock
