Mitigate excessive-fees attack in next upgrade of transaction signature hashes.

[nuttycom]

This is in relation to the possibility of excessive-fees attacks as described in
https://blog.trezor.io/details-of-firmware-updates-for-trezor-one-version-1-9-1-and-trezor-model-t-version-2-3-1-1eba8f60f2dd. The need to accommodate this change was identified in zcash/librustzcash#286 (comment):

Amounts were added to sighash following the SegWit design, but per this SegWit bug it was insufficient to protect hardware wallets from incorrectly computing fees. Given that we need everyone to migrate to a new sighash for TZE-containing transactions, we should a) fix this for TZE inputs, and b) simultaneously fix this for transparent inputs in TZE-supporting transactions.

[daira]

Depending on what other protocol features we add at the same time as TZEs, a mandatory transaction version bump might be required anyway. But I don't think anything that would require a bump is proposed (Sapling-on-Halo doesn't; transactions with neither Halo nor TZE components could still use v4 without problems).

There is also a compromise option to continue allowing v4 transactions alongside v5 but to make a mandatory change to transaction hashing, i.e. the new transaction hash would apply to v4 and v5.

[daira]

The right way to do this is to add an explicit fee field (#2163) in v6 transactions, so this is essentially a duplicate of that issue. I don't think it's necessary to retrospectively fix this problem for v4 or v5 transactions (if they are still allowed). Note that a hardware wallet could enforce the creation of v6 transactions in order to close the security issue with a malicious host.