From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WG7sY-0000ma-57 for bitcoin-development@lists.sourceforge.net; Wed, 19 Feb 2014 14:12:02 +0000 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; Received: from nk11p04mm-asmtpout002.mac.com ([17.158.236.237] helo=nk11p04mm-asmtp002.mac.com) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1WG7sW-00029q-O2 for bitcoin-development@lists.sourceforge.net; Wed, 19 Feb 2014 14:12:02 +0000 Received: from [10.6.3.42] (cpe.xe-3-1-0-415.bynqe10.dk.customer.tdc.net [188.180.67.254]) by nk11p04mm-asmtp002.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTPSA id <0N18001XWY3SFC90@nk11p04mm-asmtp002.mac.com> for bitcoin-development@lists.sourceforge.net; Wed, 19 Feb 2014 14:11:55 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87,1.0.14,0.0.0000 definitions=2014-02-19_03:2014-02-18, 2014-02-19, 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-1402190061 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 In-reply-to: Date: Wed, 19 Feb 2014 15:11:51 +0100 Message-id: References: <52FBD948.906@monetize.io> <201402122252.31060.luke@dashjr.org> 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: 1WG7sW-00029q-O2 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: Wed, 19 Feb 2014 14:12:02 -0000 --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 wrote: > On Wed, Feb 12, 2014 at 4:39 PM, Alex Morcos 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--