Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WGRLr-0000i9-84 for bitcoin-development@lists.sourceforge.net; Thu, 20 Feb 2014 10:59:35 +0000 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; Received: from nk11p04mm-asmtp001.mac.com ([17.158.236.236]) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1WGRLn-0007PO-Or for bitcoin-development@lists.sourceforge.net; Thu, 20 Feb 2014 10:59:35 +0000 Received: from [10.6.3.42] (cpe.xe-3-1-0-415.bynqe10.dk.customer.tdc.net [188.180.67.254]) by nk11p04mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTPSA id <0N1A00HIUJUZ3B00@nk11p04mm-asmtp001.mac.com> for bitcoin-development@lists.sourceforge.net; Thu, 20 Feb 2014 10:59:26 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87,1.0.14,0.0.0000 definitions=2014-02-20_05:2014-02-18, 2014-02-20, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1401130000 definitions=main-1402200026 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 In-reply-to: Date: Thu, 20 Feb 2014 11:59:22 +0100 Message-id: <81A62AB7-9EC6-439E-96CF-F064F0151BB9@mac.com> References: <52FBD948.906@monetize.io> <201402122252.31060.luke@dashjr.org> <601EE159-9022-4ADF-80AC-7E1C39E86A65@mac.com> To: Pieter Wuille X-Mailer: Apple Mail (2.1827) X-Spam-Score: -2.1 (--) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (gronager[at]mac.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.6 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1WGRLn-0007PO-Or Cc: Bitcoin Development Subject: Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 10:59:35 -0000 --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 = wrote: > On Wed, Feb 19, 2014 at 9:28 PM, Michael Gronager = 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--