Concept ACK (I vaguely recall from when we introduced PrecomputedTransactionData that it was non-negligible performance impact, I can re-check).

I'm not sure about this approach though, because SignatureHash assumes that if the cache passed in is non-NULL, then the precomputed hashes are correct, which will no longer be necessarily true.

In particular, if we wrote signing code that tried to use PrecomputedTransactionData to cache the hashes ahead of time for re-use, then I think this code would break (as the witnesses would all be NULL before the signatures are added, right?) So I think I'd prefer an approach that was easier to reason about...

@sdaftuar added a bool to indicate whether the cache is ready so it becomes fail-safe. If we want to use the cache in signing code (which is currently not), an argument could be added to PrecomputedTransactionData::PrecomputedTransactionData to request for that.

And I believe it's non-negligible. Assuming a block is full of non-witness txs (which all currently are), around 0.35MB of hashing is needed. For 100,000 blocks that'd be 35GB, which should take a few minutes at least.

Concept ACK. Probably the most important performance measure is connectTip latency at runtime, and I think this could quite possibly dominate that figure.

utACK 0da49b5

@sdaftuar @gmaxwell does it look ok?

utACK

utACK 0da49b5 (in the future we really need to figure out a way to move this into our CTransactionRef stuff so that this gets calculated once upon mempool-add and then not recalculated when we get a block containing the same transaction).

I'd be a little more comfortable with this if PrecomputedTransactionData were passed around as const, so nobody's tempted to mess with "ready" for some crazy reason. But that can always be done later.

utACK 0da49b5

Looks correct to me, utACK 0da49b5

utACK 0da49b5