This does not prevent the vulnerability, I think? Someone can still create a large number of high-(legacy)sigops transactions, and the mining code will include them, resulting in a very small block.

AFAIK the only workable solution is to treat transactions in the mempool as if their size was max(size, sigops * MAX_BLOCK_SIZE / MAX_SIGOPS).

This does not prevent the vulnerability, I think?

That's not the objective of this submission, but to remove the side effect of making multisig transactions non-standard, which was introduced by #7081, while leaving #7081 as intact as possible.

AFAIK the only workable solution is to scale up the mempool transaction size to max(size, sigops * MAX_BLOCK_SIZE / MAX_SIGOPS).

I'd be happy, if there is a better solution, and I'd be very glad, if you could push one. My primary goal was to present something that may still be merged into 0.13.

@f139975 I'll see what I can do. I understand the desire to have #8079 fixed, but not by reintroducing the attack that #7081 prevented.

Thank you!

ping @rubensayshi @NicolasDorier

@sipa The DoS being addressed here was based on actual verification time, not the miner limit. So this fix (at least as described; have not reviewed the code) should be okay. Whether the mining code wants to demand a higher fee or not, is a separate (and perhaps reasonable) issue.

Concept ACK. Would be nice if someone reopened and/or merged #5231 at the same time.

@luke-jr 20000 verification operations are allowed, and that is not currently changed by any of the proposals (neither #7081, this PR, or #8365). If that is a problem, we should propose a softfork to reduce the sigops limit, not change relay policy (which only prevents it in an easily-avoided case).

I don't see what use this serves. It makes the code more complex and doesn't constrain anyone's ability to cause computation. #8365 is sensible.

Closing in favor of #8365, which was merged today