input   scriptSig     response
output  scriptPubkey  challenge

When I steal an input (or ‘Response”) from another transaction, I take its signature as well. I don’t know the private key that goes with it but I still get the money,

Consider stealing an input which specifies a P2PK (Pay-to-Pubkey) output. Alice made a transaction, X, to pay Bob. X includes a P2PK output, x, specifying the amount to be paid, say one Bitcoin. Output x requires Bob’s signature. Bob decides to spend that Bitcoin and creates a new transaction, Y, with an input, y, designating X and x. Input y includes Bob’s signature as required by x. I don’t know Bob’s private key that produced that signature but I don’t need to. My fraudulent transaction Z includes y, bit-for-bit. If a miner picks my transaction, Z, first then the output, x, will not have been claimed and Z will pass inspection. Z also includes an output to a new address whose private key I know. Now I have stolen the Bitcoin.

I think that the following new requirement would block this fraud. It might block some currently legitimate transactions too.

The whole transaction must be signed with the same key as used in each of the inputs. better:

The whole transaction T must be signed with a key whose public version matches the public key used in any of the verifications of the inputs to T. Is this a feasible test?

Perhaps clearer:

The whole transaction includes the public key of its creator and a signature by that key of the whole transaction.
The script syntax is modified so that a response script can refer to the public key associated with the transaction to which it belongs.

This does not protect ‘multisig’ inputs. It would seem that whoever produces a transaction with a multisig input should be required to get a multisig agreement on the whole transaction. If you were part of such a consortium, would you be happy in signing an output without knowing the disposition of the funds?

This actually saves space in most transactions that include multiple inputs whose scripts are shortened.

I have little confidence that this fixes things.

Further confusion: The script command “OP_CHECKSIG” must check a signature for being from the correct private key, but what is it a signature of? The example in 4.3.1 of Okupski’s paper suggests that it does not care!

This says of OP_CHECKSIG:

The entire transaction's outputs, inputs, and script (from the most recently-executed OP_CODESEPARATOR to the end) are hashed. The signature used by OP_CHECKSIG must be a valid signature for this hash and public key. If it is, 1 is returned, 0 otherwise. About OP_CODESEPARATOR they say:

All of the signature checking words will only match signatures to the data after the most recently-executed OP_CODESEPARATOR. That sort of ties inputs to the outputs of the originating transaction. Bizarre! That thwarts the above fraud I guess.