Received-SPF: pass (sog-mx-2.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=_B811C8D1-DECA-4CA1-9E6B-C5B463AD292B";
	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: <CAAS2fgSwjGohhiXuwhG3bJ5mLxSS8Dx0Hytmg7PhhRzwnw7FNQ@mail.gmail.com>
Date: Wed, 19 Feb 2014 15:11:51 +0100
Message-id: <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>
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=_B811C8D1-DECA-4CA1-9E6B-C5B463AD292B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

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 =
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

2. In a version later one could block relay of non deterministic =
transactions, as well as the acceptance of blocks with non-confirming =
transactions.

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.

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.


On Feb 13, 2014, at 1:47 AM, Gregory Maxwell <gmaxwell@gmail.com> wrote:

> On Wed, Feb 12, 2014 at 4:39 PM, Alex Morcos <morcos@gmail.com> wrote:
>> I apologize if this has been discussed many times before.
>=20
> It has been, but there are probably many people like you who have not
> bothered researching who may also be curious.
>=20
>> As a long term solution to malleable transactions, wouldn't it be =
possible
>> to modify the signatures to be of the entire transaction.  Why do you =
have
>> to zero out the inputs?  I can see that this would be a hard fork, =
and maybe
>> it would be somewhat tricky to extract signatures first (since you =
can sign
>> everything except the signatures), but it would seem to me that this =
is an
>> important enough change to consider making.
>=20
> Because doing so would be both unnecessary and ineffective.
>=20
> Unnecessary because we can very likely eliminate malleability without
> changing what is signed. It will take time, but we have been
> incrementally moving towards that, e.g. v0.8 made many kinds of
> non-canonical encoding non-standard.
>=20
> Ineffective=97 at least as you describe it=97 because the signatures
> _themselves_ are malleable.
>=20
> =
--------------------------------------------------------------------------=
----
> Android apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience.  Start now.
> =
http://pubads.g.doubleclick.net/gampad/clk?id=3D124407151&iu=3D/4140/ostg.=
clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--Apple-Mail=_B811C8D1-DECA-4CA1-9E6B-C5B463AD292B
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

iQEcBAEBCgAGBQJTBLunAAoJEKpww0VFxdGRqo0H/2beFlzp0D2g/txVsN+Oj1m9
ufobH9xXAL2Ol0goPvDKBj0iDC/UTXO04Xh9mACLRJVmfyXJhiSGYGCNT7aBc5Dc
///SL5I+AzcDrbKWhf/yy3fDrRTcd4QZ8whcWk1vOQ/G4w9VwaHkWDAfJCXPIGi1
ViUW1tdoBfpKLSx6ovE4Mj8yv+zID9/2IEUnDb21SJl2o20m41doabVVw0A3H+42
gcXagk5g1NoNcwbDL4fAnI0GeLx74VAXZ2KQCxmXRsczhuAziIRtliflSWlgzH6C
eKFyCJHTVo9/ldOpGV8sqH8WiL1jg3AnpADwaSK4tCQuoS0TrsT4YNcB3ZoDzsk=
=VMZ4
-----END PGP SIGNATURE-----

--Apple-Mail=_B811C8D1-DECA-4CA1-9E6B-C5B463AD292B--