I think this hardfork is dead-on-arrival given the ideas for OP_CHECKSIG softforking. Instead of referring to previous transactions by a normalised hash, it makes better sense to simply change the outpoints in the signed data and allow nodes to hotfix dependent transactions when/if they are malleated. Furthermore, the approach of using a hash of scriptPubKey in the input rather than an outpoint also solves dependencies in the face of intentional malleability (respending with a higher fee, or CoinJoin, for a few examples).
These aren't barriers to making the proposal or being assigned a BIP number if you want to go forward with that, but you may wish to reconsider spending time on it. Luke On Wednesday, May 13, 2015 12:48:04 PM Christian Decker wrote: > Hi All, > > I'd like to propose a BIP to normalize transaction IDs in order to address > transaction malleability and facilitate higher level protocols. > > The normalized transaction ID is an alias used in parallel to the current > (legacy) transaction IDs to address outputs in transactions. It is > calculated by removing (zeroing) the scriptSig before computing the hash, > which ensures that only data whose integrity is also guaranteed by the > signatures influences the hash. Thus if anything causes the normalized ID > to change it automatically invalidates the signature. When validating a > client supporting this BIP would use both the normalized tx ID as well as > the legacy tx ID when validating transactions. > > The detailed writeup can be found here: > https://github.com/cdecker/bips/blob/normalized-txid/bip-00nn.mediawiki. > > @gmaxwell: I'd like to request a BIP number, unless there is something > really wrong with the proposal. > > In addition to being a simple alternative that solves transaction > malleability it also hugely simplifies higher level protocols. We can now > use template transactions upon which sequences of transactions can be built > before signing them. > > I hesitated quite a while to propose it since it does require a hardfork > (old clients would not find the prevTx identified by the normalized > transaction ID and deem the spending transaction invalid), but it seems > that hardforks are no longer the dreaded boogeyman nobody talks about. > I left out the details of how the hardfork is to be done, as it does not > really matter and we may have a good mechanism to apply a bunch of > hardforks concurrently in the future. > > I'm sure it'll take time to implement and upgrade, but I think it would be > a nice addition to the functionality and would solve a long standing > problem :-) > > Please let me know what you think, the proposal is definitely not set in > stone at this point and I'm sure we can improve it further. > > Regards, > Christian ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ Bitcoin-development mailing list Bitcoinemail@example.com https://lists.sourceforge.net/lists/listinfo/bitcoin-development