Indeed the reason I got started with all of this is the use of normalized transaction IDs within smart contracts with multiple signers. Sorry if I was perceived as overselling it :-)
So to summarize the discussions that have been on-going here as well as in the PR so far, most people seem to agree that the BIP is an improvement for smart-contracts as well as the third-party modification scenario. It comes at the cost of increased UTXO size due to the additional hash being stored per transaction with unclaimed outputs and some additional computations. The additional computation is for the normalized ID computation and the swapping in of normalized IDs during verification. No additional coin lookups are needed as they are retrieved and cached anyway when verifying the transaction. Would everybody agree with this assessment so far?
On the PR there were some additional suggestions of treating singlesig transactions as 1-of-1 transactions and using Schnorr signatures for the new opcode. Schnorr has been in the works for a long time and gives a multitude of advantages, e.g., batch validation, and seems like a good addition. Since the verify flag is mandatory due to the soft-fork migration and we might merge singlesig and multisig into a single opcode we can replace the bitmap of flags with a simple version number. Clients would fall back to OP_NOP behaviour for versions they do not implement, maintaining soft-fork semantics to build more future signing and verification methods.
On Thu, Oct 22, 2015 at 8:26 AM, Christian Decker via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Normalized transaction IDs do help in the case that the single signer wants
> to immediately follow up its transaction with another transaction spending
> the first one's change output, and it prevents any modification in the
> multi-signer scenario.
For ordinary transactions which are not performing interesting smart
contracts that particular is better addressed via canonical encoding,
which is immediately available and doesn't have the associated costs
(new pubkey type adoption, 20%-30% UTXO size increase, need for nodes
to fixup txid references, etc.).
Please, as I said up-thread: this is good and importantstuff to work
on, but it shouldn't be oversold.