<div><div dir="auto">Thank you Tom.</div><div dir="auto"><br></div><div dir="auto">Nice explanation.</div><div dir="auto"><br></div><div dir="auto">Julian</div><br><div class="gmail_quote"><div>On Thu, 7 Sep 2017 at 4:23 am, Tom Zander via bitcoin-ml <<a href="mailto:bitcoin-ml@lists.linuxfoundation.org">bitcoin-ml@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As some people seems to be spreading misunderstanings about Flexible<br>
Transactions not being canonical, I thought I’d clear that up as soon as I<br>
can.<br>
<br>
The accusation goes that since Flexible Transactions is very flexible about<br>
the ordering of tags, this becomes an issue as software could then re-encode<br>
the transaction which breaks the transaction-id.<br>
<br>
This accusation shows a misunderstanding of what the malleability attack is.<br>
The malleability attack is to change the transaction ID, *without breaking<br>
the signatures*.<br>
<br>
Flexible transactions are canonical. There is no doubt about that. There is<br>
no way to change the transaction without breaking the signatures.<br>
<br>
The normal flow of transaction creation is that a user creates a transaction,<br>
then signs it. What is important to realize that in cryptographic signing<br>
you sign a byte-array of data. Any byte is changed, reordered etc, and the<br>
signature will fail. As such, as in all crypto, the canonical format of a<br>
transaction is the list of bytes that we include in a block. When you<br>
realize this basic fact you see that deadalnix's idea makes no sense.<br>
<br>
Let me explain using less technical jargon;<br>
<br>
Imagine you sign an email. What deadalnix says is that you can't read it<br>
into MSWord and then write it out again because Word may change some details<br>
in the roundtrip. And thus that signed email would no longer validate. This<br>
is naturally true.<br>
But the action of signing the email has as its sole purpose to make it<br>
provably read-only. Anyone edits it, and the world will know. So like Word<br>
refuses to write out a document that is marked read-only, any good bitcoin<br>
software will not try to overwrite an already signed transaction.<br>
<br>
So what any software would do is check the signature and then after they<br>
realize the transaction is "Okay". Then you may read it in Word in read-only<br>
mode. But they would never ever write it out again. Its signed, you can't<br>
change it anyway.<br>
<br>
Tl;dr. A (partially) signed transaction is like a read-only document. You<br>
should treat it like such and if software tries to re-encode it, we have to<br>
conclude that you are doing it wrong.<br>
<br>
--<br>
Tom Zander<br>
Blog: <a href="https://zander.github.io" rel="noreferrer" target="_blank">https://zander.github.io</a><br>
Vlog: <a href="https://vimeo.com/channels/tomscryptochannel" rel="noreferrer" target="_blank">https://vimeo.com/channels/tomscryptochannel</a><br>
_______________________________________________<br>
bitcoin-ml mailing list<br>
<a href="mailto:bitcoin-ml@lists.linuxfoundation.org" target="_blank">bitcoin-ml@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml</a><br>
</blockquote></div></div>