Specially crafted transactions can take more than 3 minutes to verify #2256

Please read the following thread: https://bitcointalk.org/index.php?topic=140078.0

Also additional information was privately sent to the dev team.

My proposed solutions is:

1. Create a Transaction hash cache to temporarily store the last used hash during the evaluation of a script.
2. Verify that the ECDSA signature and the ECDSA public key are well-formed before hashing the transaction.
3. Verify the length of pushed signatures of vin[i].scriptSig in CTransaction::AreInputsStandard() to see if they are long enough. (currently only stack.size() = (unsigned int)nArgsExpected) is tested, but not the actual arguments. )

The first 2 defense measures must be deployed together.

see #2275

@gavinandresen Is this still unfixed?

Unfixed, but low priority-- why would a miner create a block that is likely to get orphaned because it takes peers so long to validate? And even if they did, and the block was not orphaned, all they accomplish is making full-chain catch-up validation take longer for a while (until a new release with a new checkpoint, because we skip signature checking up to the last checkpoint).

Is this still an issue?

Yes, minor.

Is it really "minor"?

It may be a DOS attack against some critical "highly trusted" peers, by forcing them to take much more time than needed, and no longer being able to cope with the incoming requests, or even being able to generate its own block (in that case, it is an attack agasist concurrent miners, made by another miner with a trick to winn the competition unfairly, and get all credits coins for being the first being able to validate a new block in the chain.

In summary: miners won't compete fairly and win much more than what they should have won, and the mining gets slower for everyone else. Such attack would likely be performed by very powerful mining farms (in China?) or profiting from very low cost for energy (in Iceland or from stealing energy resources and not paying any tax, due to some abusive local privileges, or just because they have LOT of money to spend and already have very large BTC portolio to build and run fast massive mining farms, until they are the only remaining one capable with their power to mine all the remaining boins; then they will control the BTC market by emitting/spending their mass of coins when they want, and can then largely influce the trading).

This is then a problem of unfair competition in the mining industry (and probably also in the BTC trading: abusers take no risks, all others have to support the increased risks when BTC is suddenly devaluated: abusers can use that to buy again more coins).

My understanding is that the worst case version of this can only be exploited with a non-standard transaction. On the current network there is no known miner accepting non-standard transactions (probably for exactly the bug described in this issue and others). While it may be possible to reduce the time needed to verify some of such crafted transactions with caching, implementing that is non-trivial and fixing the overall issue is to the best of my knowledge impossible without a consensus change. Such a network-wide consensus changes first need to be proposed and discussed with the greater community, for example on the bitcoin-dev mailing list. Also, it needs a BIP to be implemented in Bitcoin Core and other software that connects to the bitcoin P2P network. So I am closing this issue for now.

To clarify, I am not saying that the issue doesn't exist. The issue is real, but there is likely no trivial fix other than a consensus change. Something like "The great consensus cleanup" could be used as a baseline: https://github.com/bitcoin/bips/blob/7f9670b643b7c943a0cc6d2197d3eabe661050c2/bip-XXXX.mediawiki