<div dir="ltr">Hi William,<div><div class="gmail_extra"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I personally prefer this solution, since it nails the problem<br>
completely with one simple and obvious change. The BIP 62 approach is<br>
more like a game of wac-a-mole.<br></blockquote><div><br></div><div>The two are complementary, not competing. BIP62 prevents <b>non-signers</b> from mutating the transactions, which is very important. The &#39;Build your own nHashType&#39; proposal enables chained transactions even in the face of <b>signers</b> mutating the transaction. I believe that integrating both will lead to the best defense against transaction malleability, and will enable more complicated uses of chained transactions (such as micropayment channels).</div><div><br></div><div>Best,</div><div>Stephen</div><div><br></div><div><br></div></div></div></div></div>