Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.210.175 as permitted sender)
	client-ip=209.85.210.175; envelope-from=gmaxwell@gmail.com;
	helo=mail-ia0-f175.google.com; 
MIME-Version: 1.0
In-Reply-To: <CAPg+sBgBtYUHtHq1MnKuFJHc=NGZ4t+SxHDs0TLKmzf8bSig=g@mail.gmail.com>
References: <CAPg+sBgBtYUHtHq1MnKuFJHc=NGZ4t+SxHDs0TLKmzf8bSig=g@mail.gmail.com>
Date: Sat, 20 Oct 2012 14:34:11 -0400
Message-ID: <CAAS2fgRX9hxAhbTTXdH3P=G27sCc6D9TMu=3m1euF8P0jMEb7A@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Public key and signature malleability
Precedence: list

On Sat, Oct 20, 2012 at 1:55 PM, Pieter Wuille <pieter.wuille@gmail.com> wrote:
> 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.

I strongly support heading down this path. Malleability has produced a
steady trickle of surprising outcomes. In addition to the problems we
already know about and expect there may be additional security or DOS
problems that arise from allowing these.