diff options
| author | Michael Gronager <gronager@mac.com> | 2014-02-19 15:11:51 +0100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2014-02-19 14:12:02 +0000 |
| commit | 060fa6eeffc38355d8e904391835bf97601e9781 (patch) | |
| tree | 347e29f3ab15999701defd7f3787b08d5e6bdb69 | |
| parent | 713783156f5e4b78d94fd2795c6d0d5c33c55735 (diff) | |
| download | pi-bitcoindev-060fa6eeffc38355d8e904391835bf97601e9781.tar.gz pi-bitcoindev-060fa6eeffc38355d8e904391835bf97601e9781.zip | |
Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability
| -rw-r--r-- | b1/135a43114026cdac57124498db04f8a02290a5 | 174 |
1 files changed, 174 insertions, 0 deletions
diff --git a/b1/135a43114026cdac57124498db04f8a02290a5 b/b1/135a43114026cdac57124498db04f8a02290a5 new file mode 100644 index 000000000..4ceb950d8 --- /dev/null +++ b/b1/135a43114026cdac57124498db04f8a02290a5 @@ -0,0 +1,174 @@ +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 <gronager@mac.com>) 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 <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> +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 <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 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 <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-- + + |