I&#39;ve been working on a patch to make transaction inputs (scriptSigs) with extra data non-standard, as part of a general attitude of &quot;try to anticipate possible problems before they turn into real problems.&quot;<div>
<br></div><div>Today, any node on the network that is relaying unconfirmed transactions can add bytes to the transaction&#39;s scriptSig&#39;s before passing it on, and that modified version of the transaction will get relayed and might possibly get mined.</div>
<div><br></div><div>For example, take a standard scriptSig that is:   OP_PUSHDATA &lt;signature&gt; OP_PUSHDATA &lt;public key&gt;</div><div>... and change it to:   OP_PUSHDATA &lt;Hi Mom!&gt; OP_PUSHDATA &lt;signature&gt; OP_PUSHDATA &lt;public key&gt;<br clear="all">
<div>... and the modified transaction will pass all of the IsStandard(), IsValid(), and OP_CHECKSIG checks.</div><div><br></div><div>That is... unexpected, especially since it changes the transaction id.  You might transmit a transaction with ID 123 but find out it has been mined as transaction ID 456.  Satoshi&#39;s code doesn&#39;t care (it just looks like an attempted double-spend of the coins), but I wouldn&#39;t be surprised if it caused problems for other implementations or other transaction-handling software.</div>
<div><br></div><div>My patch will make transactions with extra stuff in the scriptSig non-standard, so they won&#39;t get relayed or mined by new nodes. Alternative implementations will still have to deal with all types of double-spends, of course, and there are other ways of producing two transactions that are identical except for their scriptSigs  (you can generate an arbitrary number of valid signatures for a transaction if you have the private keys, for example) so this isn&#39;t a panacea for poorly-implemented bitcoin transaction handling software. But it does remove some &quot;wiggle room,&quot; which is generally a good idea for improving security.</div>
<div><br></div><div><br></div><div>I&#39;m still thinking about how much further to go with this:</div><div><br></div><div>+ I think requiring that the &lt;signature&gt; and &lt;public key&gt; be DER-encoded for the transaction to be IsStandard() is a good idea.  DER encoding defines a canonical way of representing data; Satoshi&#39;s code relies on OpenSSL to decode signatures and public keys, and OpenSSL accepts any, more general, BER encoding.</div>
<div><br></div><div>+ I&#39;m tempted to require that the &quot;filler item&quot; to workaround the OP_CHECKMULTISIG pops-one-too-many-items-off-the-stack bug be exactly OP_0.</div><div><br></div><div>Discussion welcome; I should be making a pull request for my patch this afternoon.</div>
<br>--<br>Gavin Andresen<br><br>
</div>