Sync stopped at 382452 with error: block contains too many signature operations - got 20001, max 20000

[romainPellerin]

I am running a bchd node with txindex=1 and addrindex=1 and was syncing it for the past few days, it stopped at block height 382452:

2018-10-07 18:24:30.513 [INF] SYNC: Rejected block 00000000000000000a3acbef6eaa006b653bebccd2cff7228e499832739aea07 from 54.90.148.132:8333 (outbound): block contains too many signature operations - got 20001, max 20000
2018-10-07 18:26:26.526 [INF] SYNC: Rejected block 0000000000000000005e4051f988f84efc2334f033bd3d2071c7af336fa4f65e from 54.90.148.132:8333 (outbound): previous block 00000000000000000a3acbef6eaa006b653bebccd2cff7228e499832739aea07 is known to be invalid
2018-10-07 18:27:09.402 [INF] CHAN: Adding orphan block 0000000000000000082ac7db995ea28840848fa97658dc3c23dccec810bcda27 with parent 0000000000000000005e4051f988f84efc2334f033bd3d2071c7af336fa4f65e
2018-10-07 18:27:09.752 [INF] CHAN: Adding orphan block 00000000000000000e4b183a44e6fc1aceb142ce8eda3cda71e9b36b5c16a09a with parent 0000000000000000082ac7db995ea28840848fa97658dc3c23dccec810bcda27

I will go ahead and get the last version of bchd, but is this a none issue @cpacia ?

[romainPellerin]

Built from last code, it gives me the same result.

[tyler-smith]

I'm seeing this as well. Same block.

[cpacia]

The block in question is from 2015. So it's not choking on a > 1mb block.

[cpacia]

I did see that issue when I synced but it's possible the bug was introduced after I synced.

[cpacia]

Only thing I can think of is maybe it's counting OP_CHECKDATASIG and that pushed it over the limit. But that opcode should have been (and still is) invalid so I don't know why a block would contain it.

[cpacia]

So the code is counting OP_CHECKDATASIG https://github.com/gcash/bchd/blob/master/txscript/script.go#L617

But I don't know how this part of the code is being reached by this block as the block should not contain any OP_CHECKDATASIGs

[tyler-smith]

I lost my chain data on accident and it's taking forever to resync. @romainPellerin any chance you can send me yours to I can test this OP_CHECKDATASIG theory?

[cpacia]

I can send you mine. But I think you need to copy the data before you test because it will mark the block as invalid and not process it again after that.

[tyler-smith]

Cool, sounds good.

[zquestz]

So when that block was created the op code was different. Any chance someone spammed the chain with:

OP_UNKNOWN186 = 0xba // 186

Then the bytes would match this condition... I think we need to put a guard on this increment based on whether the nov upgrade is active.

[tyler-smith]

Good call. That definitely needs to be dependent on the fork being active to be correct.

[tyler-smith]

I'll examine the block when I it to confirm that's the only issue here.

[cpacia]

Oh it's the coinbase input script that contains the offending opcodes. Which is why it's passing validation since the input isn't validated.

Not sure why max sig ops is being checked on the coinbase though.

[cpacia]

Looking at the ABC code I think the coinbase input script is counted. They use a flag to decide whether or not to count the CHECKDATASIG. Maybe #51 is the best way to handle it.

[zquestz]

Fixed.