<p dir="ltr">Regarding chains of transactions intended to be published at once together, wouldn&#39;t it be easier to add a &quot;only-mine-with-child flag&quot;?</p>
<p dir="ltr">That way the parent transactions aren&#39;t actually valid unless spent together with the transaction that depends on it, and only the original will have a child referencing it.</p>
<p dir="ltr">Then malleability is not an issue at all for transaction chains if you only need to broadcast your full transaction chain once, and don&#39;t need to extend it in two or more occasions, *after* broadcasting subchains to the network, from the same set of pregenerated transactions.</p>

<p dir="ltr">If you need to broadcast pregenerated subchains separately, then you need the last child in the chain to be non-malleable. </p>
<p dir="ltr">This would require all miners to start to respect it at once in order to avoid forking the network. </p>
<p dir="ltr">- Sent from my phone</p>
<div class="gmail_quote">Den 19 feb 2014 22:13 skrev &quot;Pieter Wuille&quot; &lt;<a href="mailto:pieter.wuille@gmail.com">pieter.wuille@gmail.com</a>&gt;:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, Feb 19, 2014 at 9:28 PM, Michael Gronager &lt;<a href="mailto:gronager@mac.com">gronager@mac.com</a>&gt; wrote:<br>
&gt; I think that we could guarantee fewer incidents by making version 1 transactions unmalleable and then optionally introduce a version 3 that supported the malleability feature. That way most existing problematic implementations would be fixed and no doors were closed for people experimenting with other stuff - tx v 3 would probably then be called experimental transactions.<br>

<br>
Just to be clear: this change is not directly intended to avoid<br>
&quot;incidents&quot;. It will take way too long to deploy this. Software should<br>
deal with malleability. This is a longer-term solution intended to<br>
provide non-malleability guarantees for clients that a) are upgraded<br>
to use them ┬áb) willing to restrict their functionality. As there are<br>
several intended use cases for malleable transactions (the sighash<br>
flags pretty directly are a way to signify what malleabilities are<br>
*wanted*), this is not about outlawing malleability.<br>
<br>
While we could right now make all these rules non-standard, and<br>
schedule a soft fork in a year or so to make them illegal, it would<br>
mean removing potential functionality that can only be re-enabled<br>
through a hard fork. This is significantly harder, so we should think<br>
about it very well in advance.<br>
<br>
About new transaction and block versions: this allows implementing and<br>
automatically scheduling a softfork without waiting for wallets to<br>
upgrade. The non-DER signature change was discussed for over two<br>
years, and implemented almost a year ago, and we still notice wallets<br>
that don&#39;t support it. We can&#39;t expect every wallet to be instantly<br>
modified (what about hardware wallets like the Trezor, for example?<br>
they may not just be able to be upgraded). Nor is it necessary: if<br>
your software only spends confirmed change, and tracks all debits<br>
correctly, there is no need.<br>
<br>
--<br>
Pieter<br>
<br>
------------------------------------------------------------------------------<br>
Managing the Performance of Cloud-Based Applications<br>
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.<br>
Read the Whitepaper.<br>
<a href="http://pubads.g.doubleclick.net/gampad/clk?id=121054471&amp;iu=/4140/ostg.clktrk" target="_blank">http://pubads.g.doubleclick.net/gampad/clk?id=121054471&amp;iu=/4140/ostg.clktrk</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development" target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
</blockquote></div>