tx malleability for altcoins

[MentalCollatz]

Since transaction malleability is the result of the fact that multiple valid scriptSigs can be used to sign the same transaction, and the scriptsSig is included in the transaction hash, could the malleability problem be solved by simply not including them in the hash (just hashing inputs and outputs)?  I can't think of an obvious vulnerability this would introduce.  Such a hard-fork seems beyond the realm of possibility for Bitcoin, but new altcoins could certainly adopt it if it works.  Are there any problems that arise from such an approach, and do any altcoins currently hash transactions this way?

Edit: this was moved from the technical board to the altcoin board.  While I can see why that happened, my primary interest was purely technical, and I don't think I'm as likely to get the response I want here.

[virtualx]

Since transaction malleability is the result of the fact that multiple valid scriptSigs can be used to sign the same transaction, and the scriptsSig is included in the trad the realm of possibility for Bitcoin, bunsaction hash, could the malleability problem be solved by simply not including them in the hash (just hashing inputs and outputs)?  I can't think of an obvious vulnerability this would introduce.  Such a hard-fork seems beyont new altcoins could certainly adopt it if it works.  Are there any problems that arise from such an approach, and do any altcoins currently hash transactions this way?

Many altcoins are simply forks of the bitcoin source code with a few modifications, they hash transactions like bitcoin.  Only a handful of them have started heavy modifications or starting from scratch but I do not know if they hash transactions in another way.

[MentalCollatz]

Managed to answer my own question.  Not including scriptSigs in the hash leads to a vulnerability where an attacker broadcasts a modified version of a block which contains too many sigops, causing a node to reject a valid block as invalid.  I conclude that the transaction hash for the merkle root must include scriptSigs, however it should be okay to use a different mechanism to compute the transaction id.

[spartacusrex]

You could include a hash of the correct scriptsig (only the static bits) that is required in the txn ?

Then, only a scriptsig that hashed to the value AND was correct would be valid.

[var53]

Managed to answer my own question.  Not including scriptSigs in the hash leads to a vulnerability where an attacker broadcasts a modified version of a block which contains too many sigops, causing a node to reject a valid block as invalid.  I conclude that the transaction hash for the merkle root must include scriptSigs, however it should be okay to use a different mechanism to compute the transaction id.

When Bitcoin had the tx malleability problems people said it was Bitcoin feature and any problems were the exchange's faults for not writing their software correctly. I think most Bitcoin exchanges modified their software afterwards to prevent problems. Did all the alt coin exchanges modify their software to prevent any problems?

[MentalCollatz]

You could include a hash of the correct scriptsig (only the static bits) that is required in the txn ?

But how do you decide which scriptSig is "correct"?  This is one of the challenges the Bitcoin developers are currently facing - attempting to define a set of rules to make sure only one version of a scriptSig is considered "correct".

When Bitcoin had the tx malleability problems people said it was Bitcoin feature and any problems were the exchange's faults for not writing their software correctly. I think most Bitcoin exchanges modified their software afterwards to prevent problems. Did all the alt coin exchanges modify their software to prevent any problems?

I've seen people justify many of Bitcoin's deficiencies as features, but that's a discussion for another place and time.  There are some benefits to non-malleable transactions besides being more robust against bad/uneducated programmers (which by itself is a good enough reason, IMHO).  For example you can create transactions that use the outputs of another transaction before that transaction is signed.

[spartacusrex]

My understanding of it - the problem arises because the signature you send with your txn is actually a script. You could add OP_NOP instructions to the script, keeping it valid, but changing the TXN id (hash of the txn+scriptsig). 

How about this. It requires a double sign.

You construct a txn.

You sign it with your valid scriptsig.

You hash all of that. And sign that hash.

You then send the txn with the HASH signature.

A txn is only valid if it is sent with the hash of itself signed by the sender.

This way you cannot change the scriptsig, as the hash would change.

?