Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of mac.com
	designates 17.158.236.237 as permitted sender)
	client-ip=17.158.236.237; envelope-from=gronager@mac.com;
	helo=nk11p04mm-asmtp002.mac.com; 
Content-type: multipart/signed;
	boundary="Apple-Mail=_DB92BE89-E5A2-4C70-98AF-D6F26116E3D8";
	protocol="application/pgp-signature"; micalg=pgp-sha512
MIME-version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Michael Gronager <gronager@mac.com>
In-reply-to: <CAPg+sBgnuNygR7_yny1=+wGWmeLcub0A8_ep3U-5ewmQJk71jw@mail.gmail.com>
Date: Wed, 19 Feb 2014 21:28:24 +0100
Message-id: <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>
To: Pieter Wuille <pieter.wuille@gmail.com>
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with
 malleability
Precedence: list


--Apple-Mail=_DB92BE89-E5A2-4C70-98AF-D6F26116E3D8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Twisting your words a bit I read:

* you want to support relay of transactions that can be changed on the =
fly, but you consider it wrong to modify them.
* #3 is already not forwarded, but you still find it relevant to support =
it.

Rational use cases of #3 will be pretty hard to find given the fact that =
they can be changed on the fly. We are down to inclusion in blocks by =
miners for special purposes - or did I miss out something?

I think that we could guarantee fewer incidents by making version 1 =
transactions unmalleable and then optionally introduce a version 3 that =
supported the malleability feature. That way most existing problematic =
implementations would be fixed and no doors were closed for people =
experimenting with other stuff - tx v 3 would probably then be called =
experimental transactions.

/M


On Feb 19, 2014, at 3:38 PM, Pieter Wuille <pieter.wuille@gmail.com> =
wrote:

> 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:
>>=20
>> 1. the next bitcoin version "prettify" all relayed transactions as =
deterministic transactions fulfilling the scheme 1-6 effectively =
blocking any malleability attack? If miners would upgrade then all =
transactions in blocks would have a deterministic hash.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
>> 2. In a version later one could block relay of non deterministic =
transactions, as well as the acceptance of blocks with non-confirming =
transactions.
>>=20
>> To non-standard conforming clients this "prettify" change of hash =
would be seen as a constant malleability attack, but given the =
"prettify" code it is to fix any client into producing only conforming =
transactions, just by running the transaction through it before =
broadcast.
>>=20
>> 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 conforming transaction in a block and only introduce 2. once that =
number is sufficiently small for a certain duration - criteria:
>> * Switch on forcing of unmalleable transactions in blocks when there =
has been only conforming transactions for 1000 blocks.
>=20
> 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
> --=20
> Pieter


--Apple-Mail=_DB92BE89-E5A2-4C70-98AF-D6F26116E3D8
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJTBRPpAAoJEKpww0VFxdGRrKsIAKJtwyKXkNS5/DbeTR87uRGy
duOx9Q9DHQ4007HisddM+l4kdhbyieTUbjY7XAaW2chrJePSda1Pwt4RQWLVU6OV
Oxx70G7T4KyQdlWDQs6fpyGx7KfYL9HX7a7BVkIZ7spaVyLVMcWZmUqnnx6pV37o
ZvyWFMUOQFpJD0U9Ur4N5kM1p+1JEA4b4LgGMlpYoDn6dd/VaNuW28QjJQZy9hdn
Vc6oItKbHrWa/YpU2IvtU8DRBy7bRx5ERy4NjHlCZU4wKkyPqN42u4vF7SqzKO+i
3JMRAS654H1pgz+Yi5diTDEZxcZhWJai7qQTzy2qDPN3q6HS7F4O6yuyHXCDr/4=
=0W6T
-----END PGP SIGNATURE-----

--Apple-Mail=_DB92BE89-E5A2-4C70-98AF-D6F26116E3D8--