Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of mac.com
	designates 17.158.236.236 as permitted sender)
	client-ip=17.158.236.236; envelope-from=gronager@mac.com;
	helo=nk11p04mm-asmtp001.mac.com; 
Content-type: multipart/signed;
	boundary="Apple-Mail=_444DF93C-91C2-4663-8127-BD9165A5DC9B";
	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+sBg9=XK=PGSW8DcU1LR85oeTDmpS4U-vYUXbraZQpU+edg@mail.gmail.com>
Date: Thu, 20 Feb 2014 11:59:22 +0100
Message-id: <81A62AB7-9EC6-439E-96CF-F064F0151BB9@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>
	<CAPg+sBg9=XK=PGSW8DcU1LR85oeTDmpS4U-vYUXbraZQpU+edg@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=_444DF93C-91C2-4663-8127-BD9165A5DC9B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

As I see the BIP it is basically stressing that ver 1 transactions are =
malleable.

It then addresses the need for unmalleable transactions for e.g. =
spending unconfirmed outputs in a deterministic way (i.e. no 3rd party =
can sabotage) - this transaction type is defined as ver 3.

A lot of clients today spend unconfirmed outputs (even bitcoin-qt) and =
as such make an implicit assumption that this is kind of safe, which it =
is not - it can be intervened and sabotaged through tx malleability.

What I suggested was to ensure that a subclass of version 1 transactions =
become unmalleable - namely those with sighash=3Dall. Note that only the =
sender can modify the sighash as it is part of the hash signed. So =
instead of defining a version 3, we could constrain version 1 txes with =
sighash=3Dall to have a unmalleable hash. If you e.g. would like to =
still have a sighash=3Dall type of transaction with malleable features =
you can simply use that sighash=3Dall today is checked for using =
sighash&0x1f=3Dsighash_all, so just OR'ing with 0x20 or 0x40 will get =
you the 'old' feature.

I do however buy the argument of Peter and Gregory that there might =
exist unpublished transactions out there that does not even conform to =
the DER rules etc, and as such we cannot forbid them from being mined, =
nor can we timestamp them and include 'only the old ones'. Hence we =
cannot change the consensus rule for version 1 transactions - and only =
changing the relay rules will not provide a certain guarantee.

So, I think the two line argument for the BIP is as follows:
1. We cannot change the consensus rules for version 1 transactions as =
that might invalidate unpublished non-standard transactions (=3D voiding =
peoples money, which is a line we don't want to cross)
2. The prime usecase for unmalleable transactions is being able to spend =
unconfirmed outputs - this is done today by almost all clients, but it =
is really broken. Hence a need for a fix asap.

I am all in favor for the BIP, but I expect the realistic timeline for =
enforced version 3 transactions is roughly one year, which is better =
than two, but it would have been nice to get it faster...

/M


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

> 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 =
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.
>=20
> 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.
>=20
> 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.
>=20
> 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
> --=20
> Pieter


--Apple-Mail=_444DF93C-91C2-4663-8127-BD9165A5DC9B
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

iQEcBAEBCgAGBQJTBeAKAAoJEKpww0VFxdGRoF0IAKMLoavmnFfISaQqatOev2qb
YBfEScfZliAI6F2o23Cb4r1VawTi7RiedCNqUJVCZSU5wjMtDMMqgcsdSkJaQYov
rQmovU3ZwGkStIG05Cv5ag4MHt/3ny9DlztBCO0w50zoluaHY51d5D67M4AYn6sV
SeP7YalOcka1X2NjdrEV0bk5oFsdPhYHpK6sd42xTcWcjIWdzTWkEUV4nPsVJ7Yx
1BPfXaK2+xJoq0dVru1cybZWn7XB9DzyvqZC6OS/kEuD890T8CipJwlVcOAeEdue
65XhXE8S08ZtPXgHgrRLxgPRlwje9nr8FMpwUh/Flv+UV3UCMN5w744PorDn/S0=
=VdU8
-----END PGP SIGNATURE-----

--Apple-Mail=_444DF93C-91C2-4663-8127-BD9165A5DC9B--