<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, May 13, 2015 at 6:14 PM, Pieter Wuille <span dir="ltr">&lt;<a href="mailto:pieter.wuille@gmail.com" target="_blank">pieter.wuille@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p dir="ltr">Normalized transaction ids are only effectively non-malleable when all inputs they refer to are also non-malleable (or you can have malleability in 2nd level dependencies), so I do not believe it makes sense to allow mixed usage of the txids at all.</p></blockquote><div><br></div><div>The txid or txid-norm is signed, so can&#39;t be changed after signing.  <br><br>The hard fork is to allow transactions to refer to their inputs by txid or txid-norm.  You pick one before signing.<br></div><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p dir="ltr"> They do not provide the actual benefit of guaranteed non-malleability before it becomes disallowed to use the old mechanism.</p></blockquote><div>A signed transaction cannot have its txid changed.  It is true that users of the system would have to use txid-norm.<br><br></div><div>The basic refund transaction is as follows.<br></div><div><br></div><div> A creates TX1: &quot;Pay w BTC to &lt;B&#39;s public key&gt; if signed by A &amp; B&quot;<br> <br> A creates TX2: &quot;Pay w BTC from TX1-norm to &lt;A&#39;s public key&gt;, locked 48 hours in the future, signed by A&quot;<br> <br> A sends TX2 to B<br> <br> B signs TX2 and returns to A<br><br></div><div>A broadcasts TX1.  It is mutated before entering the chain to become TX1-mutated.<br><br></div><div>A can still submit TX2 to the blockchain, since TX1 and TX1-mutated have the same txid-norm.<br></div> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p dir="ltr">That, together with the +- resource doubling needed for the UTXO set (as earlier mentioned) and the fact that an alternative which is only a softfork are available, makes this a bad idea IMHO.</p>
<p dir="ltr">Unsure to what extent this has been presented on the mailinglist, but the softfork idea is this:<br>
* Transactions get 2 txids, one used to reference them (computed as before), and one used in an (extended) sighash.<br>
* The txins keep using the normal txid, so not structural changes to Bitcoin.<br>
* The ntxid is computed by replacing the scriptSigs in inputs by the empty string, and by replacing the txids in txins by their corresponding ntxids.<br>
* A new checksig operator is softforked in, which uses the ntxids in its sighashes rather than the full txid.<br>
* To support efficiently computing ntxids, every tx in the utxo set (currently around 6M) stores the ntxid, but only supports lookup bu txid still.</p>
<p dir="ltr">This does result in a system where a changed dependency indeed invalidates the spending transaction, but the fix is trivial and can be done without access to the private key.</p></blockquote><div>The problem with this is that 2 level malleability is not protected against.<br><br></div><div>C spends B which spends A.<br></div><br><div></div><div>A is mutated before it hits the chain.  The only change in A is in the scriptSig.<br><br>B can be converted to B-new without breaking the signature.  This is because the only change to A was in the sciptSig, which is dropped when computing the txid-norm.<br><br></div><div>B-new spends A-mutated.  B-new is different from B in a different place.  The txid it uses to refer to the previous output is changed.<br><br></div><div>The signed transaction C cannot be converted to a valid C-new.  The txid of the input points to B.  It is updated to point at B-new.  B-new and B don&#39;t have the same txid-norm, since the change is outside the scriptSig.  This means that the signature for C is invalid.<br></div><div></div><div><br></div><div>The txid replacements should be done recursively.  All input txids should be replaced by txid-norms when computing the txid-norm for the transaction.  I think this repairs the problem with only allowing one level?<br><br></div><div>Computing txid-norm:<br><br></div><div>- replace all txids in inputs with txid-norms of those transactions<br></div><div>- replace all input scriptSigs with empty scripts<br></div><div>- transaction hash is txid-norm for that transaction<br><br></div><div>The same situation as above is not fatal now.<br><br><div>C spends B which spends A.<br></div><br><div>A is mutated before it hits the chain.  The only change in A is in the scriptSig.<br><br>B
 can be converted to B-new without breaking the signature.  This is 
because the only change to A was in the sciptSig, which is dropped when 
computing the txid-norm (as before).<br><br></div><div>B-new spends A mutated.  
B-new is different from B in for the previous inputs.  <br><br>The input for B-new points to A-mutated.  When computing the txid-norm, that would be replaced with the txid-norm for A.<br><br></div><div>Similarly, the input for B points to A and that would have been replaced with the txid-norm for A.<br><br></div><div>This means that B and B-new have the same txid-norm.<br></div><div><br></div><div>The signed 
transaction C can be converted to a valid C-new.  The txid of the
 input points to B.  It is updated to point at B-new.  B-new and B now have
 have the same txid-norm and so C is valid.<br><br></div><div>I think this reasoning is valid, but probably needs writing out actual serializations.<br></div></div></div></div></div>