Regarding the re-hashing the transaction data once per input being a bottleneck, I was mistakenly only thinking about this from the point of view of the signer. Full nodes have to check all transactions' inputs, which is much more costly, as the link Gavin posted shows.

On Thu, Apr 9, 2015 at 10:45 AM, Mike Hearn <mike@plan99.net> wrote:

Right, good point. I wonder if this sort of auto forwarding could even be a useful feature. I can't think of one right now.

I can think of a few convoluted use cases, but not any good ones. People have definitely looked for this feature before, though, just look at this Bitcoin SE post. I think there are better ways to handle key management than auto-forwarding, though. Anyone looking for this feature probably just wasn't aware that there are better solutions.

On Thu, Apr 9, 2015 at 10:45 AM, Mike Hearn <mike@plan99.net> wrote:

Yes but is that fundamental or is there a way to avoid it? That's what I'm getting at.

In the bitcointalk article referenced, Sergio actually gave us the answer:

> Hash(Tx,previn-index) = Hash ( Hash(outputs) || Hash (Inputs-with-script-cleared) || <previn-index> )
> (for SIGHASH_ALL)
> This way the values "Hash(outputs)" and "Hash(Inputs-with-script-cleared)" can be cached and reused.

Basically, just re-order the way stuff is serialized. Put the stuff that is nearly always signed at the beginning, and vice versa. I'll see if I can update the proposal to make this optimization possible. What I suspect, though, is that with all the new controls, blocks with ordinary transactions will verify faster, but an attacker could still create a very CPU intensive block by signing inputs with a wide variety of nHashTypes and then signing the last one with the equivalent of SIGHASH_ALL. I don't think that's a big limitation, though, the attack is already somewhat possible, and would be very hard to do, and doesn't really gain the attacker anything (other than infamy).

On Thu, Apr 9, 2015 at 1:28 PM, Peter Todd <pete@petertodd.org> wrote:

For the OP: Have you looked at how CODESEPARATOR allows the signature to
sign code to run as part of verifying the signature? E.g. my signature
can say "valid if you run these additional opcodes and they return true"
where those additional opcodes take the transaction, hash it in the
defined way, and verify that the ECC signature correctly signs that
hash and the hash of the additional opcodes. For instance in this case
making a signature that's only valid if the tx fee is less than the
defined amount would be a matter of GET_FEE <max fee + 1> LESSTHAN VERIFY

I've never been able to really see a good use case for OP_CODESEPARATOR, and I'm not sure I completely have my head wrapped around what you're proposing. From this and this, though, it seems like OP_CODESEPARATOR cannot really be made useful unless you already have a way to sign without hashing the TXIDs referenced by your input, in which case you need to modify the nHashType.

Best,
Stephen