From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1TPdH3-00055N-Sj for bitcoin-development@lists.sourceforge.net; Sat, 20 Oct 2012 17:55:49 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.175 as permitted sender) client-ip=209.85.214.175; envelope-from=pieter.wuille@gmail.com; helo=mail-ob0-f175.google.com; Received: from mail-ob0-f175.google.com ([209.85.214.175]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1TPdH3-0006QB-3R for bitcoin-development@lists.sourceforge.net; Sat, 20 Oct 2012 17:55:49 +0000 Received: by mail-ob0-f175.google.com with SMTP id eq6so1444656obc.34 for ; Sat, 20 Oct 2012 10:55:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.21.135 with SMTP id v7mr3350197obe.101.1350755743382; Sat, 20 Oct 2012 10:55:43 -0700 (PDT) Received: by 10.76.143.38 with HTTP; Sat, 20 Oct 2012 10:55:43 -0700 (PDT) Date: Sat, 20 Oct 2012 19:55:43 +0200 Message-ID: From: Pieter Wuille To: Bitcoin Dev Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: -1.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 (pieter.wuille[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -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: 1TPdH3-0006QB-3R Subject: [Bitcoin-development] Public key and signature malleability 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: Sat, 20 Oct 2012 17:55:50 -0000 Hello all, as some may be aware, OpenSSL accepts several encodings for the same public key or the same signature. It even accepts encodings that fail to conform to the SEC and DER specification by which they are defined. As it perfectly capable of parsing every standard-compliant encoding, this is not a problem on itself. However, as near every full Bitcoin node in existence uses OpenSSL, they will accept such non-standard encodings in transactions, and even let them into blocks. In order to make the Bitcoin network rules more well-defined, I'd like to propose strict rules about what is acceptable, and which do not depend on OpenSSL's implementation. This would make it easier for alternative full node implementations, and prevent "malleability attacks". For that, I've submitted a pull request some time ago (see https://github.com/bitcoin/bitcoin/pull/1742). The specific rules are these: * For public keys (SEC compressed or uncompressed EC points) * First byte is either 0x02, 0x03 or 0x04 * If the first byte is 0x02 or 0x03, exactly 32 bytes follow * If the first byte is 0x04, exactly 64 bytes follow * For signatures (DER encoded integer pairs) * Format is 0x30 0x02 0x02 * R and S are MSB encoded integers, which encode a non-negative integer without excessive zero bytes in front. This implies they do not start with a 0x00 unless the next byte has its highest bit set (>=0x80) or are 0, in which case exactly one 0x00 is required. Their length is thus between 1 and 33 bytes. * is a single byte that is either 0x01, 0x02, 0x03, 0x81, 0x82 or 0x83. All these are rules that are followed by almost all clients already (including Armory and Bitcoin-js, which until recently didn't). Sergio Lerner recently discovered that one can take the secp256k1-field-size complement of the S value in the signature without invalidating it. The easiest solution to prevent this, would be to require that the lowest bit of the S value is always even (as taking the complement changes this). This would require some coordination, as no client currently enforces this, but it is easy to implement. The reason malleability can be a problem, is that a malicious relayer can modify transactions in-transit without invalidating them. This will not cause any loss of coins, but a lot of wallet software wouldn't deal gracefully with a modified version of their transactions that gets accepted in a block. What do you think about these rules? If people want these rules, nothing would happen for now - just start try to find software that doesn't produce complying data. In a second step, these could be enabled as check similar to IsStandard() - making it hard for them to get into blocks, but still be accepted when they aren't standard. Finally, when no significant amount of non-standard transactions are seen anymore, we can write a BIP and start enforcing this as a network rule. -- Pieter