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-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from <mh.in.england@gmail.com>) id 1WGUJG-0006Gj-90 for bitcoin-development@lists.sourceforge.net; Thu, 20 Feb 2014 14:09:06 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.50 as permitted sender) client-ip=209.85.219.50; envelope-from=mh.in.england@gmail.com; helo=mail-oa0-f50.google.com; Received: from mail-oa0-f50.google.com ([209.85.219.50]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WGUJE-00026j-UJ for bitcoin-development@lists.sourceforge.net; Thu, 20 Feb 2014 14:09:06 +0000 Received: by mail-oa0-f50.google.com with SMTP id n16so2121244oag.37 for <bitcoin-development@lists.sourceforge.net>; Thu, 20 Feb 2014 06:08:59 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.182.219.167 with SMTP id pp7mr1535098obc.85.1392905339512; Thu, 20 Feb 2014 06:08:59 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.76.71.231 with HTTP; Thu, 20 Feb 2014 06:08:59 -0800 (PST) Received: by 10.76.71.231 with HTTP; Thu, 20 Feb 2014 06:08:59 -0800 (PST) In-Reply-To: <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> <81A62AB7-9EC6-439E-96CF-F064F0151BB9@mac.com> Date: Thu, 20 Feb 2014 14:08:59 +0000 X-Google-Sender-Auth: HEsQuUBzV_ONhi7-dn93ZXxohtQ Message-ID: <CANEZrP26U3BjEi66xjD9SRxrAupGmYC6mKiYYw27BH3q1b1hLQ@mail.gmail.com> From: Mike Hearn <mike@plan99.net> To: =?UTF-8?Q?Michael_Gr=C3=B8nager?= <gronager@mac.com> Content-Type: multipart/alternative; boundary=089e0141ab82f7add504f2d70b84 X-Spam-Score: -0.5 (/) 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 (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1WGUJE-00026j-UJ Cc: Bitcoin Dev <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: Thu, 20 Feb 2014 14:09:06 -0000 --089e0141ab82f7add504f2d70b84 Content-Type: text/plain; charset=UTF-8 We've done forking changes before much faster than a year and that was with less experience. If we want, we can get this done within months. On 20 Feb 2014 16:30, "Michael Gronager" <gronager@mac.com> wrote: > 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=all. 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=all > to have a unmalleable hash. If you e.g. would like to still have a > sighash=all type of transaction with malleable features you can simply use > that sighash=all today is checked for using sighash&0x1f=sighash_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 (= 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. > > > > 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. > > > > 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. > > > > 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. > > > > -- > > Pieter > > > > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > > http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > --089e0141ab82f7add504f2d70b84 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <p dir=3D"ltr">We've done forking changes before much faster than a yea= r and that was with less experience. If we want, we can get this done withi= n months.</p> <div class=3D"gmail_quote">On 20 Feb 2014 16:30, "Michael Gronager&quo= t; <<a href=3D"mailto:gronager@mac.com">gronager@mac.com</a>> wrote:<= br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:0= 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> As I see the BIP it is basically stressing that ver 1 transactions are mall= eable.<br> <br> It then addresses the need for unmalleable transactions for e.g. spending u= nconfirmed outputs in a deterministic way (i.e. no 3rd party can sabotage) = - this transaction type is defined as ver 3.<br> <br> A lot of clients today spend unconfirmed outputs (even bitcoin-qt) and as s= uch make an implicit assumption that this is kind of safe, which it is not = - it can be intervened and sabotaged through tx malleability.<br> <br> What I suggested was to ensure that a subclass of version 1 transactions be= come unmalleable - namely those with sighash=3Dall. Note that only the send= er can modify the sighash as it is part of the hash signed. So instead of d= efining a version 3, we could constrain version 1 txes with sighash=3Dall t= o 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.<= br> <br> I do however buy the argument of Peter and Gregory that there might exist u= npublished transactions out there that does not even conform to the DER rul= es etc, and as such we cannot forbid them from being mined, nor can we time= stamp 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.<br> <br> So, I think the two line argument for the BIP is as follows:<br> 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)<br> 2. The prime usecase for unmalleable transactions is being able to spend un= confirmed outputs - this is done today by almost all clients, but it is rea= lly broken. Hence a need for a fix asap.<br> <br> I am all in favor for the BIP, but I expect the realistic timeline for enfo= rced version 3 transactions is roughly one year, which is better than two, = but it would have been nice to get it faster...<br> <br> /M<br> <br> <br> On Feb 19, 2014, at 10:11 PM, Pieter Wuille <<a href=3D"mailto:pieter.wu= ille@gmail.com">pieter.wuille@gmail.com</a>> wrote:<br> <br> > On Wed, Feb 19, 2014 at 9:28 PM, Michael Gronager <<a href=3D"mailt= o:gronager@mac.com">gronager@mac.com</a>> wrote:<br> >> I think that we could guarantee fewer incidents by making version = 1 transactions unmalleable and then optionally introduce a version 3 that s= upported the malleability feature. That way most existing problematic imple= mentations would be fixed and no doors were closed for people experimenting= with other stuff - tx v 3 would probably then be called experimental trans= actions.<br> ><br> > Just to be clear: this change is not directly intended to avoid<br> > "incidents". It will take way too long to deploy this. Softw= are should<br> > deal with malleability. This is a longer-term solution intended to<br> > provide non-malleability guarantees for clients that a) are upgraded<b= r> > to use them =C2=A0b) willing to restrict their functionality. As there= are<br> > several intended use cases for malleable transactions (the sighash<br> > flags pretty directly are a way to signify what malleabilities are<br> > *wanted*), this is not about outlawing malleability.<br> ><br> > While we could right now make all these rules non-standard, and<br> > schedule a soft fork in a year or so to make them illegal, it would<br= > > mean removing potential functionality that can only be re-enabled<br> > through a hard fork. This is significantly harder, so we should think<= br> > about it very well in advance.<br> ><br> > About new transaction and block versions: this allows implementing and= <br> > automatically scheduling a softfork without waiting for wallets to<br> > upgrade. The non-DER signature change was discussed for over two<br> > years, and implemented almost a year ago, and we still notice wallets<= br> > that don't support it. We can't expect every wallet to be inst= antly<br> > modified (what about hardware wallets like the Trezor, for example?<br= > > they may not just be able to be upgraded). Nor is it necessary: if<br> > your software only spends confirmed change, and tracks all debits<br> > correctly, there is no need.<br> ><br> > --<br> > Pieter<br> <br> <br>-----------------------------------------------------------------------= -------<br> Managing the Performance of Cloud-Based Applications<br> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.<br> Read the Whitepaper.<br> <a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D121054471&iu= =3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam= pad/clk?id=3D121054471&iu=3D/4140/ostg.clktrk</a><br>__________________= _____________________________<br> Bitcoin-development mailing list<br> <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo= pment@lists.sourceforge.net</a><br> <a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development= " target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment</a><br> <br></blockquote></div> --089e0141ab82f7add504f2d70b84--