Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Rnurt-0003l7-9s for bitcoin-development@lists.sourceforge.net; Thu, 19 Jan 2012 16:29:41 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.82.175 as permitted sender) client-ip=74.125.82.175; envelope-from=gavinandresen@gmail.com; helo=mail-we0-f175.google.com; Received: from mail-we0-f175.google.com ([74.125.82.175]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Rnurn-0007Dm-Of for bitcoin-development@lists.sourceforge.net; Thu, 19 Jan 2012 16:29:41 +0000 Received: by werb12 with SMTP id b12so127360wer.34 for ; Thu, 19 Jan 2012 08:29:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.131.153 with SMTP id m25mr11588016wei.9.1326990569627; Thu, 19 Jan 2012 08:29:29 -0800 (PST) Received: by 10.223.112.199 with HTTP; Thu, 19 Jan 2012 08:29:29 -0800 (PST) Date: Thu, 19 Jan 2012 11:29:29 -0500 Message-ID: From: Gavin Andresen To: Bitcoin Dev Content-Type: multipart/alternative; boundary=0016e6de17f985e27b04b6e41132 X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (gavinandresen[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1Rnurn-0007Dm-Of Subject: [Bitcoin-development] Extending IsStandard() to transaction scriptSigs X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 16:29:41 -0000 --0016e6de17f985e27b04b6e41132 Content-Type: text/plain; charset=ISO-8859-1 I've been working on a patch to make transaction inputs (scriptSigs) with extra data non-standard, as part of a general attitude of "try to anticipate possible problems before they turn into real problems." Today, any node on the network that is relaying unconfirmed transactions can add bytes to the transaction's scriptSig's before passing it on, and that modified version of the transaction will get relayed and might possibly get mined. For example, take a standard scriptSig that is: OP_PUSHDATA OP_PUSHDATA ... and change it to: OP_PUSHDATA OP_PUSHDATA OP_PUSHDATA ... and the modified transaction will pass all of the IsStandard(), IsValid(), and OP_CHECKSIG checks. 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's code doesn't care (it just looks like an attempted double-spend of the coins), but I wouldn't be surprised if it caused problems for other implementations or other transaction-handling software. My patch will make transactions with extra stuff in the scriptSig non-standard, so they won'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't a panacea for poorly-implemented bitcoin transaction handling software. But it does remove some "wiggle room," which is generally a good idea for improving security. I'm still thinking about how much further to go with this: + I think requiring that the and be DER-encoded for the transaction to be IsStandard() is a good idea. DER encoding defines a canonical way of representing data; Satoshi's code relies on OpenSSL to decode signatures and public keys, and OpenSSL accepts any, more general, BER encoding. + I'm tempted to require that the "filler item" to workaround the OP_CHECKMULTISIG pops-one-too-many-items-off-the-stack bug be exactly OP_0. Discussion welcome; I should be making a pull request for my patch this afternoon. -- Gavin Andresen --0016e6de17f985e27b04b6e41132 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I've been working on a patch to make transaction inputs (scriptSigs) wi= th extra data non-standard, as part of a general attitude of "try to a= nticipate possible problems before they turn into real problems."

Today, any node on the network that is relaying unconfirmed = transactions can add bytes to the transaction's scriptSig's before = passing it on, and that modified version of the transaction will get relaye= d and might possibly get mined.

For example, take a standard scriptSig that is: =A0 OP_= PUSHDATA <signature> OP_PUSHDATA <public key>
... and= change it to: =A0 OP_PUSHDATA <Hi Mom!>=A0OP_PUSHDATA <signature&= gt; OP_PUSHDATA <public key>
... and the modified transaction will pass all of the IsStandard(), Is= Valid(), and OP_CHECKSIG checks.

That is... unexpe= cted, especially since it changes the transaction id. =A0You might transmit= a transaction with ID 123 but find out it has been mined as transaction ID= 456. =A0Satoshi's code doesn't care (it just looks like an attempt= ed double-spend of the coins), but I wouldn't be surprised if it caused= problems for other implementations or other transaction-handling software.=

My patch will make transactions with extra stuff in the= scriptSig non-standard, so they won't get relayed or mined by new node= s. Alternative implementations will still have to deal with all types of do= uble-spends, of course, and there are other ways of producing two transacti= ons that are identical except for their scriptSigs =A0(you can generate an = arbitrary number of valid signatures for a transaction if you have the priv= ate keys, for example) so this isn't a panacea for poorly-implemented b= itcoin transaction handling software. But it does remove some "wiggle = room," which is generally a good idea for improving security.


I'm still thinking about how much fu= rther to go with this:

+ I think requiring that th= e <signature> and <public key> be DER-encoded for the transacti= on to be IsStandard() is a good idea. =A0DER encoding defines a canonical w= ay of representing data; Satoshi's code relies on OpenSSL to decode sig= natures and public keys, and OpenSSL accepts any, more general, BER encodin= g.

+ I'm tempted to require that the "filler item= " to workaround the OP_CHECKMULTISIG pops-one-too-many-items-off-the-s= tack bug be exactly OP_0.

Discussion welcome; I sh= ould be making a pull request for my patch this afternoon.

--
Gavin Andresen

--0016e6de17f985e27b04b6e41132--