From: Gavin Andresen <gavinandresen@gmail•com>
To: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: [Bitcoin-development] Extending IsStandard() to transaction scriptSigs
Date: Thu, 19 Jan 2012 11:29:29 -0500 [thread overview]
Message-ID: <CABsx9T2Hh-qb6CwMdD-Ov_qT6pg=muqO4uY1=+ccCxhVLUU5Gw@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2366 bytes --]
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 <signature>
OP_PUSHDATA <public key>
... and change it to: OP_PUSHDATA <Hi Mom!> OP_PUSHDATA <signature>
OP_PUSHDATA <public key>
... 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 <signature> and <public key> 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
[-- Attachment #2: Type: text/html, Size: 2754 bytes --]
reply other threads:[~2012-01-19 16:29 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CABsx9T2Hh-qb6CwMdD-Ov_qT6pg=muqO4uY1=+ccCxhVLUU5Gw@mail.gmail.com' \
--to=gavinandresen@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox