Ok, getting the ball rolling again after some downtime. I amended the proposal to use a simple version number instead of the binary flags, added the normalization of inputs before computing the signaturehash and added Schnorr signatures as requested.
The BIP has also been assigned number 130 :-)
I am still very much intrigued by Luke's idea of having empty scriptsigs and ship the signatures in external scripts, however the proposal uses the on-the-fly normalization because we have no good way of relaying the external scripts. Since we are still in the drafting phase I am open to suggestions and if there is a good/working solution I can amend/withdraw the proposal.
As for open venues for malleability, I'm not sure we can fix them at all, after all the ability of a single signer to doublespend by appending/replacing inputs/outputs in an arbitrary fashion is not fixable IMHO and will cause any future transaction building on its outputs to be orphaned. What would the perfect properties for such a fix be?
Regards,
Christian
On Thursday, October 22, 2015 8:26:58 AM Christian Decker wrote:
> I think the scenario of the single signer re-ordering the outputs and
> inputs and then re-signing the transaction is in the same category of
> simple double-spends. The signer could just as well sign a completely
> different transaction spending the same coins to somewhere else, so I don't
> think there is a lot we can do about it even if we instate a canonical
> ordering. Even if we order the inputs and outputs the signer can just add a
> new input and output and we would have a different transaction.
>
> 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.
Except that unlike malicious double spending, adding more outputs to
unconfirmed transactions is what wallets *should ideally be doing every time
they send another transaction*. Spending unconfirmed change is the wrong
approach. So half-fixing malleability as this PR would, encourages
inefficient behaviour in multiple ways (first, by not making it malleability-
safe; second, by encouraging spending unconfirmed change).
Luke