ERROR: ConnectBlock(): too many sigops / InvalidChainFound: invalid block=...

(1/3) > >>

Cricktor:
I've just seen this in the debug.log of my Core bitcoind (v24.0.1):
Code:

...
2023-04-01T07:29:55Z UpdateTip: new best=00000000000000000001244128897a9f32c24ca0e7ee578063f8580deed9ccb7 height=783425 version=0x20800000 log2_work=94.093200 tx=819475866 date='2023-04-01T07:29:18Z' progress=1.000000 cache=5.5MiB(22491txo)
2023-04-01T07:29:56Z BlockUntilSyncedToCurrentChain: txindex is catching up on block notifications
2023-04-01T07:30:56Z New outbound peer connected: version: 70016, blocks=783425, peer=17965 (outbound-full-relay)
2023-04-01T07:31:28Z Socks5() connect to <redacted>.onion:8333 failed: host unreachable
2023-04-01T07:33:29Z ERROR: ConnectBlock(): too many sigops
2023-04-01T07:33:29Z InvalidChainFound: invalid block=00000000000000000002ec935e245f8ae70fc68cc828f05bf4cfa002668599e4 height=783426 log2_work=94.093214 date=2023-04-01T07:32:51Z
2023-04-01T07:33:29Z InvalidChainFound: current best=00000000000000000001244128897a9f32c24ca0e7ee578063f8580deed9ccb7 height=783425 log2_work=94.093200 date=2023-04-01T07:29:18Z
2023-04-01T07:33:29Z ERROR: ConnectTip: ConnectBlock 00000000000000000002ec935e245f8ae70fc68cc828f05bf4cfa002668599e4 failed, bad-blk-sigops
2023-04-01T07:33:29Z InvalidChainFound: invalid block=00000000000000000002ec935e245f8ae70fc68cc828f05bf4cfa002668599e4 height=783426 log2_work=94.093214 date=2023-04-01T07:32:51Z
2023-04-01T07:33:29Z InvalidChainFound: current best=00000000000000000001244128897a9f32c24ca0e7ee578063f8580deed9ccb7 height=783425 log2_work=94.093200 date=2023-04-01T07:29:18Z
2023-04-01T07:35:20Z UpdateTip: new best=00000000000000000004e0ec4f27bd3347381e8e19ed98d7f918e8c1c292ae97 height=783426 version=0x21386000 log2_work=94.093214 tx=819477925 date='2023-04-01T07:34:57Z' progress=1.000000 cache=4.7MiB(15485txo)
...

What's the reason, that one of my peers tries to relay a block with "too many sigops"? I assume the following InvalidChainFound errors are a result of the first error condition that ConnectBlock() spitted out. Malicious peer node? Bug in Core?

I'm curious to hear some explanations, please.

BlackHatCoiner:
Quote from: Cricktor on April 01, 2023, 08:42:05 AM

I assume the following InvalidChainFound errors are a result of the first error condition that ConnectBlock() spitted out.

Yes, Bitcoin Core has a limit on the number of sigops in a block. From consensus.h, it's set to 80,000. That is consensus rule.

Quote from: Cricktor on April 01, 2023, 08:42:05 AM

What's the reason, that one of my peers tries to relay a block with "too many sigops"?
It's indeed weird. There is either some malicious node out there, or a miner who failed to to validate the block properly. Maybe some Bitcoin Core developer can enlighten us.

Cricktor:
In the meantime I learned, not verified though, that a mined block might at the very beginning be propagated by only its block header and then there's also Compact Block Relay. The block header of the too-many-sigops-block seemed to be valid, while its block content wasn't. So block header only relay wouldn't have detected the error at first, only after a valid node had checked the full block and detect the consensus violation, it would've dropped the block as faulty.

But take this with a big pinch of salt as I clearly am lacking detail knowledge here.

pooya87:
Quote from: Cricktor on April 01, 2023, 10:31:11 AM

In the meantime I learned, not verified though, that a mined block might at the very beginning be propagated by only its block header and then there's also Compact Block Relay. The block header of the too-many-sigops-block seemed to be valid, while its block content wasn't. So block header only relay wouldn't have detected the error at first, only after a valid node had checked the full block and detect the consensus violation, it would've dropped the block as faulty.

But take this with a big pinch of salt as I clearly am lacking detail knowledge here.

That's only for receiving blocks not for relaying them. In other words the nodes must not relay the header alone before fully verifying the block itself. If a node sent you an invalid block that node is either malicious or a broken/buggy implementation.

Additionally compact block feature is about reducing your node's traffic consumption. Basically your node already has most of the transactions that are waiting to be confirmed in its mempool and a new block usually contains transactions that you already have in your mempool (verified). So your node can skip re-downloading and re-verifying them and instead download the parts it doesn't already have.

P.S. I wish you shared the entire block not just its hash if you had it.

garlonicon:
Quote

P.S. I wish you shared the entire block not just its hash if you had it.
It seems my full node has it, here you are: https://pastebin.com/ETVD9yf9

Edit: I guess the coinbase transaction can be also needed:
Code:

$ ./bitcoin-cli getrawtransaction eb6e6080a351e20f840741b56b1d92f920d19a1bb1dc10970dfa6e0fdc032dea true 00000000000000000002ec935e245f8ae70fc68cc828f05bf4cfa002668599e4
{
"in_active_chain": false,
"txid": "eb6e6080a351e20f840741b56b1d92f920d19a1bb1dc10970dfa6e0fdc032dea",
"hash": "d44c787805d9ec5f06540d89f6945e281bf50f2df4b6664237e0292b7e7f96e7",
"version": 1,
"size": 424,
"vsize": 397,
"weight": 1588,
"locktime": 1049682829,
"vin": [
{
"coinbase": "0342f40b2cfabe6d6d76eebeccd7ca22e72d1f7c18b9a3ae8c3f93c04072e77b94dfcf0f0dd560be4410000000f09f909f092f4632506f6f6c2f66000000000000000000000000000000000000000000000000000000000000000000000005007c000000",
"txinwitness": [
"0000000000000000000000000000000000000000000000000000000000000000"
],
"sequence": 0
}
],
"vout": [
{
"value": 6.50925715,
"n": 0,
"scriptPubKey": {
"asm": "OP_DUP OP_HASH160 c825a1ecf2a6830c4401620c3a16f1995057c2ab OP_EQUALVERIFY OP_CHECKSIG",
"desc": "addr(1KFHE7w8BhaENAswwryaoccDb6qcT6DbYY)#flw9lhul",
"hex": "76a914c825a1ecf2a6830c4401620c3a16f1995057c2ab88ac",
"address": "1KFHE7w8BhaENAswwryaoccDb6qcT6DbYY",
"type": "pubkeyhash"
}
},
{
"value": 0.00000000,
"n": 1,
"scriptPubKey": {
"asm": "OP_RETURN aa21a9edf8b71f0213d7b0bc1cefcfe26f15f0faeb470790cdf2fa733e372e2ac86dbd9b",
"desc": "raw(6a24aa21a9edf8b71f0213d7b0bc1cefcfe26f15f0faeb470790cdf2fa733e372e2ac86dbd9b)#mxdkcvex",
"hex": "6a24aa21a9edf8b71f0213d7b0bc1cefcfe26f15f0faeb470790cdf2fa733e372e2ac86dbd9b",
"type": "nulldata"
}
},
{
"value": 0.00000000,
"n": 2,
"scriptPubKey": {
"asm": "OP_RETURN 434f524501bc0fbef688bca8f9ec86c688cdfbe6e0fe6086e9bdb2a04b4ccf74792cc6753c27c5fd5f1d6458bf",
"desc": "raw(6a2d434f524501bc0fbef688bca8f9ec86c688cdfbe6e0fe6086e9bdb2a04b4ccf74792cc6753c27c5fd5f1d6458bf)#ckn567kp",
"hex": "6a2d434f524501bc0fbef688bca8f9ec86c688cdfbe6e0fe6086e9bdb2a04b4ccf74792cc6753c27c5fd5f1d6458bf",
"type": "nulldata"
}
},
{
"value": 0.00000000,
"n": 3,
"scriptPubKey": {
"asm": "OP_RETURN 48617468541f47c104f1690e5ff047144796590532263943499eb325769b2b4abe54e4a2",
"desc": "raw(6a2448617468541f47c104f1690e5ff047144796590532263943499eb325769b2b4abe54e4a2)#9a9g966l",
"hex": "6a2448617468541f47c104f1690e5ff047144796590532263943499eb325769b2b4abe54e4a2",
"type": "nulldata"
}
},
{
"value": 0.00000000,
"n": 4,
"scriptPubKey": {
"asm": "OP_RETURN 52534b424c4f434b3a8faeec671a86c6204caaab8ee63d185f62fa271a6ca971fd84e9851e004f05e5",
"desc": "raw(6a4c2952534b424c4f434b3a8faeec671a86c6204caaab8ee63d185f62fa271a6ca971fd84e9851e004f05e5)#cy0daxqf",
"hex": "6a4c2952534b424c4f434b3a8faeec671a86c6204caaab8ee63d185f62fa271a6ca971fd84e9851e004f05e5",
"type": "nulldata"
}
}
],
"hex": "010000000001010000000000000000000000000000000000000000000000000000000000000000ffffffff640342f40b2cfabe6d6d76eebeccd7ca22e72d1f7c18b9a3ae8c3f93c04072e77b94dfcf0f0dd560be4410000000f09f909f092f4632506f6f6c2f66000000000000000000000000000000000000000000000000000000000000000000000005007c00000000000000059356cc26000000001976a914c825a1ecf2a6830c4401620c3a16f1995057c2ab88ac0000000000000000266a24aa21a9edf8b71f0213d7b0bc1cefcfe26f15f0faeb470790cdf2fa733e372e2ac86dbd9b00000000000000002f6a2d434f524501bc0fbef688bca8f9ec86c688cdfbe6e0fe6086e9bdb2a04b4ccf74792cc6753c27c5fd5f1d6458bf0000000000000000266a2448617468541f47c104f1690e5ff047144796590532263943499eb325769b2b4abe54e4a200000000000000002c6a4c2952534b424c4f434b3a8faeec671a86c6204caaab8ee63d185f62fa271a6ca971fd84e9851e004f05e5012000000000000000000000000000000000000000000000000000000000000000008de3903e",
"blockhash": "00000000000000000002ec935e245f8ae70fc68cc828f05bf4cfa002668599e4",
"confirmations": 0
}

Navigation

 Message Index