<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, May 19, 2015 at 9:28 AM, Christian Decker <span dir="ltr">&lt;<a href="mailto:decker.christian@gmail.com" target="_blank">decker.christian@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span style="font-size:13.1999998092651px;line-height:19.7999992370605px">Thanks Stephen, I hadn&#39;t thought about BIP 34 and we need to address this in both proposals. </span><span style="font-size:13.1999998092651px;line-height:19.7999992370605px">If we can avoid it I&#39;d like not to have one transaction hashed one way and other transactions in another way.</span></div></blockquote><div><br></div><div>The normalized TXID cannot depend on height for other transactions.  Otherwise, it gets mutated when been added to the chain, depending on height.<br><br></div><div>An option would be that the height is included in the scriptSig for all transactions, but for non-coinbase transctions, the height used is zero.<br><br></div><div>I think if height has to be an input into the normalized txid function, the specifics of inclusion don&#39;t matter.<br></div><div><br></div><div>The previous txid for coinbases are required to be all zeros, so the normalized txid could be to add the height to the txids of all inputs.  Again, non-coinbase transactions would have heights of zero.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><span style="font-size:13.1999998092651px;line-height:19.7999992370605px">Is there a specific reason why that was not chosen at the time?<br></span></div></div></blockquote><div><br></div><div>I assumed that since the scriptSig in the coinbase is specifically intended to be &quot;random&quot; bytes/extra nonce, so putting a restriction on it was guaranteed to be backward compatible.<br></div><div> </div></div></div></div>