QTUM mainnet generate block unstable

[Pencil-Yao]

I watch qtum for a long time, I just wonder qtum block generation was so unstable. for empty block, the block generation would be soon, less than official setting 128s block: 352220-352224 On contrast when the block was fat, the block generateion would be slow, more than official setting 128s block: 352225 block: 352231 352235 https://qtum.info/block/?date=2019-04-11

I saw qtum v0.17.2 code, the generation block target space is 128s(nPowTargetSpacing) and We know qtum use blackcoin's pos consensus, core func CheckStakeKernelHash, its annotation:

// BlackCoin kernel protocol // coinstake must meet hash target according to the protocol: // kernel (input 0) must meet the formula // hash(nStakeModifier + blockFrom.nTime + txPrev.vout.hash + txPrev.vout.n + nTime) < bnTarget * nWeight

if pos calculation failed, the minging node would need to remind the whole block, and before remind the node would sleep 5000ms(in the mine core func ThreadStakeMiner). I wonder whether this sleep time would make generation block unstable. Although no direct evidence and random appearance, I only see when long time(>5min) interval between the current block and parent block, the current block always has much fee or gas. Does fat block influences generation block? Where the time cost?

Qtum Core Daemon version mainnet-ignition-v0.17.2

Linux ebserver-natasha 4.15.0-47-generic #50~16.04.1-Ubuntu SMP Fri Mar 15 16:06:21 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

[xuanyan0x7c7]

Qtum blocks are always generated at the timestamp divided by 16, so 5000ms sleep doesn't matter

[Pencil-Yao]

Qtum blocks are always generated at the timestamp divided by 16, so 5000ms sleep doesn't matter

This would reduce block mining speed badly, but I just wonder fat block would had a big influence on the block generation.

Ps. how to prevent from time attack which Jameson Lopp had article, https://medium.com/@lopp/bitcoin-timestamp-security-8dcfc3914da6

[mischasirius]

(edit) Seems like this could be because of verification taking a long time. Does anyone know if smart contracts are executed after finding the correct hash?

On Thu, Apr 11, 2019, 11:36 Yieazy notifications@github.com wrote:

Qtum blocks are always generated at the timestamp divided by 16, so 5000ms sleep doesn't matter

This would reduce block mining speed badly, but I just wonder fat block would had a big influence on the block generation.

Ps. how to prevent from time attack which Jameson Lopp had article, https://medium.com/@lopp/bitcoin-timestamp-security-8dcfc3914da6

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/qtumproject/qtum/issues/667#issuecomment-482042998, or mute the thread https://github.com/notifications/unsubscribe-auth/AhMBGvv80a3XHwaL_aYGb1fy_j2Bx-auks5vfwIYgaJpZM4cpGsr .

[Pencil-Yao]

-aggressive-staking is safe?

[JB395]

Qtum block consensus takes a few seconds to 20 – 30 minutes, realized in 16 second intervals, averaging 144 seconds (currently). Staking wallets check every 16 seconds if their SHA256 hash calculation is < target * wallet weight. The hash serves as a random number generator, hence the variation in block spacing.

Transactions arrive in the memory pool with their own random pattern. Blocks with longer spacings will naturally hold more transactions. If transactions arrived uniformly then a block with 128 second spacing would have twice as many transactions as a block with 64 second spacing, but the number of transactions waiting in the memory pool (and subsequent size of the block) is unrelated to the random consensus process.

See more on the Qtum retargeting algorithm in https://github.com/qtumproject/qips/issues/9