Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.213.182 as permitted sender)
	client-ip=209.85.213.182; envelope-from=pieter.wuille@gmail.com;
	helo=mail-ig0-f182.google.com; 
MIME-Version: 1.0
In-Reply-To: <EFA82A3F-2907-4B2B-9FCB-DCA02CA4EC63@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>
Date: Wed, 19 Feb 2014 15:38:19 +0100
Message-ID: <CAPg+sBgnuNygR7_yny1=+wGWmeLcub0A8_ep3U-5ewmQJk71jw@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 3:11 PM, Michael Gronager <gronager@mac.com> wrote:
> Why introduce a new transaction version for this purpose ? Wouldn't it be=
 more elegant to simply let:
>
> 1. the next bitcoin version "prettify" all relayed transactions as determ=
inistic transactions fulfilling the scheme 1-6 effectively blocking any mal=
leability attack? If miners would upgrade then all transactions in blocks w=
ould have a deterministic hash.

I consider actively mutating other's transactions worse than not
relaying them. If we want people to make their software deal with
malleability, either will work.

Regarding deterministic hash: that's impossible. Some signature hash
types are inherently (and intentionally) malleable. I don't think we
should pretend to want to change that. The purpose is making
non-malleability a choice the sender of a transaction can make.

Most of the rules actually are enforced by IsStandard already now.
Only #1 and #7 aren't. #1 affects the majority of all transactions, so
changing it right now would be painful. #7 only affects multisig.

> 2. In a version later one could block relay of non deterministic transact=
ions, as well as the acceptance of blocks with non-confirming transactions.
>
> To non-standard conforming clients this "prettify" change of hash would b=
e seen as a constant malleability attack, but given the "prettify" code it =
is to fix any client into producing only conforming transactions, just by r=
unning the transaction through it before broadcast.
>
> There is a possible fork risk in step 2. above - if a majority of miners =
still havn't upgraded to 1 when 2 is introduced. We could monitor % non con=
forming transaction in a block and only introduce 2. once that number is su=
fficiently small for a certain duration - criteria:
> * Switch on forcing of unmalleable transactions in blocks when there has =
been only conforming transactions for 1000 blocks.

The problem in making these rules into consensus rule (affecting
tx/block validity) is that some rules (in particular #3) may not be
wanted by everyone, as they effectively limit the possibilities of the
script language further. As it is ultimately only about protecting
senders who care about non-malleability, introducing a new transaction
version is a very neat way of accomplishing that. The new block
version number is only there to coordinate the rollout, and choosing
an automatic forking point.

--=20
Pieter