Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.213.174 as permitted sender)
	client-ip=209.85.213.174; envelope-from=pieter.wuille@gmail.com;
	helo=mail-ig0-f174.google.com; 
MIME-Version: 1.0
In-Reply-To: <601EE159-9022-4ADF-80AC-7E1C39E86A65@mac.com>
References: <CAPg+sBgPG+2AMbEHSRQNFn6FikbRzxkWduj5MSZLz-O6Wh940w@mail.gmail.com>
	<CALf2ePwc=es-aDSeJO2DZwu9kyHwq9dcp5TrMAhN-dvYwNjy-w@mail.gmail.com>
	<52FBD948.906@monetize.io> <201402122252.31060.luke@dashjr.org>
	<CAPWm=eV9YP3wAbCFt1JcSqJ6Jc3kY_546MVk3cHT+X8seC8vRw@mail.gmail.com>
	<CAAS2fgSwjGohhiXuwhG3bJ5mLxSS8Dx0Hytmg7PhhRzwnw7FNQ@mail.gmail.com>
	<EFA82A3F-2907-4B2B-9FCB-DCA02CA4EC63@mac.com>
	<CAPg+sBgnuNygR7_yny1=+wGWmeLcub0A8_ep3U-5ewmQJk71jw@mail.gmail.com>
	<601EE159-9022-4ADF-80AC-7E1C39E86A65@mac.com>
Date: Wed, 19 Feb 2014 22:11:14 +0100
Message-ID: <CAPg+sBg9=XK=PGSW8DcU1LR85oeTDmpS4U-vYUXbraZQpU+edg@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Michael Gronager <gronager@mac.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with
	malleability
Precedence: list

On Wed, Feb 19, 2014 at 9:28 PM, Michael Gronager <gronager@mac.com> wrote:
> I think that we could guarantee fewer incidents by making version 1 trans=
actions unmalleable and then optionally introduce a version 3 that supporte=
d the malleability feature. That way most existing problematic implementati=
ons would be fixed and no doors were closed for people experimenting with o=
ther stuff - tx v 3 would probably then be called experimental transactions=
.

Just to be clear: this change is not directly intended to avoid
"incidents". It will take way too long to deploy this. Software should
deal with malleability. This is a longer-term solution intended to
provide non-malleability guarantees for clients that a) are upgraded
to use them  b) willing to restrict their functionality. As there are
several intended use cases for malleable transactions (the sighash
flags pretty directly are a way to signify what malleabilities are
*wanted*), this is not about outlawing malleability.

While we could right now make all these rules non-standard, and
schedule a soft fork in a year or so to make them illegal, it would
mean removing potential functionality that can only be re-enabled
through a hard fork. This is significantly harder, so we should think
about it very well in advance.

About new transaction and block versions: this allows implementing and
automatically scheduling a softfork without waiting for wallets to
upgrade. The non-DER signature change was discussed for over two
years, and implemented almost a year ago, and we still notice wallets
that don't support it. We can't expect every wallet to be instantly
modified (what about hardware wallets like the Trezor, for example?
they may not just be able to be upgraded). Nor is it necessary: if
your software only spends confirmed change, and tracks all debits
correctly, there is no need.

--=20
Pieter