Signature hashing of transactions incorrect/surprising for multiple inputs. about elements

[gwillen]

Yeah, everything you say is true. :-( I will make sure this gets fixed one way or another before the next release -- I'm rewriting some stuff around it anyway. Thanks!

[gwillen]

@sipa As I recall, you objected strongly to the approach I originally used for signing values, which was to add the value to the CTxIn. Unfortunately it's now seeming even more like that is going to be needed if we want to be able to sign the values of all inputs we're hashing over, not just the one we're currently signing for. We could definitely try to pass them all in when signing, but it's not clear they'll be as readily available.

Alternatively we could just not sign the values of the other inputs (perhaps that's what you had in mind.) But especially since we're moving towards flexibility on which inputs/outputs get signed, it would be nice not to have to skip that. (We could, I suppose, only sign the current input's value IF we are signing in default "sign-all" mode, and require the values of any other to-be-signed inputs to be directly supplied if signing in bitmask mode.)

Thoughts?

[rustyrussell]

Just hash the value for the being-consumed output after you've hashed all the inputs.

There's no reason to hash the value of the other outputs anyway; you only care that this one doesn't change, and the other outputs will get committed by the other inputs' signatures.

[instagibbs]

This seems like pre-segwit discussions... closing