From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from <gronager@mac.com>) id 1WGDl9-0005tI-L5 for bitcoin-development@lists.sourceforge.net; Wed, 19 Feb 2014 20:28:47 +0000 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; Received: from nk11p04mm-asmtpout002.mac.com ([17.158.236.237] helo=nk11p04mm-asmtp002.mac.com) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1WGDl2-0005tf-Mw for bitcoin-development@lists.sourceforge.net; Wed, 19 Feb 2014 20:28:47 +0000 Received: from [10.0.1.102] (2508ds5-oebr.1.fullrate.dk [90.184.5.129]) 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 <0N1900LC4FJDGYA0@nk11p04mm-asmtp002.mac.com> for bitcoin-development@lists.sourceforge.net; Wed, 19 Feb 2014 20:28:28 +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_05: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-1402190126 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> 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: 1WGDl2-0005tf-Mw Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net> 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: <bitcoin-development.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> List-Post: <mailto:bitcoin-development@lists.sourceforge.net> List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> X-List-Received-Date: Wed, 19 Feb 2014 20:28:47 -0000 --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--