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 ) 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 ; 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: <52FBD948.906@monetize.io> <201402122252.31060.luke@dashjr.org> <601EE159-9022-4ADF-80AC-7E1C39E86A65@mac.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: From: Mike Hearn To: =?UTF-8?Q?Michael_Gr=C3=B8nager?= 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 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 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" 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 > 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. > > > > 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

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.

On 20 Feb 2014 16:30, "Michael Gronager&quo= t; <gronager@mac.com> wrote:<= br type=3D"attribution">
As I see the BIP it is basically stressing that ver 1 transactions are mall= eable.

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.

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.

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>
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.

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 un= confirmed outputs - this is done today by almost all clients, but it is rea= lly broken. Hence a need for a fix asap.

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...

/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 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.
>
> Just to be clear: this change is not directly intended to avoid
> "incidents". It will take way too long to deploy this. Softw= are 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 =C2=A0b) 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<= br> > 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<= br> > that don't support it. We can't expect every wallet to be inst= antly
> 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/gam= pad/clk?id=3D121054471&iu=3D/4140/ostg.clktrk
__________________= _____________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--089e0141ab82f7add504f2d70b84--