<!DOCTYPE html><html><head>
<style type="text/css">body { font-family:'Times New Roman'; font-size:13px}</style>
</head>
<body><div>
<div><br></div><blockquote style="margin: 0 0 0.80ex; border-left: #0000FF 2px solid; padding-left: 1ex"><div dir="ltr"><div>Longer term it would be more ideal have a canonical identifier for the transaction before it even gets to the chain to support these use cases, even if wallets are able to properly identify the status of it's transactions. &nbsp;</div>
<div><br></div><div>-Allen</div></div><div class="gmail_extra"><br><br></div></blockquote></div><div>
<div>One possible work-around to get back trusted transaction chaining for payment channels and locked refunds from multi-sig would be to make the initial transaction include zero fee, and depend on child-pays-for-parent in order to get the first and follow-on transactions into a block. This of course only works for protocols where the parties don't need the initial funding transaction to actually hit the blockchain right away.</div><div><br></div><div>But this relies on two assumptions; 1) that miners won't include a zero-fee transaction in the blockchain, and 2) that miners actually implement child-pays-for-parent. It's definitely not the same security as-if you had immutable txid, but it's something to consider.</div></div><div><br></div><div>
<div>1) Mutants may cause wallet spam and difficulty calculating balance (and wallets will evolve to deal with it)</div><div>2) Mutants cause DoS because they can interfere with your own transaction chains, which for example makes batch off-line processing much more difficult</div><div>3) Mutants introduce a 3rd party attacker into any two-party protocol that relies on chains</div></div><div><br></div><div>There's a lot to digest in the 'v3' transaction/block proposal. It sounds like there may be some uncertainty over whether we can *prove* that v3 transactions in v3 blocks would actually be guaranteed immutable with these changes?</div><div><br></div><div>If we cannot fully prove a Tx is immutable, then is it actually worth taking steps to make it seem immutable, or is that just a false sense of security in the cases where chained transactions were actually expected to be reliable? Under that thinking, maybe it's best to accept mutants as a fact of life, and only consider protocols and techniques that cannot be broken by mutants.</div><div><br></div><div>In what cases does reducing the sources of malleability, but not necessarily eliminating from a security proof perspective, actually help? Basically, if we don't know that we will succeed, isn't there really no point in trying?</div></body></html>