Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WGV5A-0000ax-VZ for bitcoin-development@lists.sourceforge.net; Thu, 20 Feb 2014 14:58:37 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.213.41 as permitted sender) client-ip=209.85.213.41; envelope-from=gavinandresen@gmail.com; helo=mail-yh0-f41.google.com; Received: from mail-yh0-f41.google.com ([209.85.213.41]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WGV59-0001Xa-Kn for bitcoin-development@lists.sourceforge.net; Thu, 20 Feb 2014 14:58:36 +0000 Received: by mail-yh0-f41.google.com with SMTP id f73so747827yha.14 for ; Thu, 20 Feb 2014 06:58:30 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.236.101.18 with SMTP id a18mr3657307yhg.65.1392908310150; Thu, 20 Feb 2014 06:58:30 -0800 (PST) Received: by 10.170.133.213 with HTTP; Thu, 20 Feb 2014 06:58:30 -0800 (PST) In-Reply-To: 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 09:58:30 -0500 Message-ID: From: Gavin Andresen To: Gregory Maxwell Content-Type: multipart/alternative; boundary=20cf3010ea2508051804f2d7bd17 X-Spam-Score: -0.6 (/) 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 (gavinandresen[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 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: 1WGV59-0001Xa-Kn 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:58:37 -0000 --20cf3010ea2508051804f2d7bd17 Content-Type: text/plain; charset=ISO-8859-1 Great, I'm hearing rough consensus to proceed with Pieter's plan. RE: far from confident on malleability routes: I'm reasonably confident that we can squash malleability for IsStandard, SIGHASH_ALL transactions. A proper proof of DSA signature un-malleability (or an lower bound for how much work it would be to create a valid doppleganger signature) would be great, but I don't think it is necessary to proceed. On Thu, Feb 20, 2014 at 9:36 AM, Gregory Maxwell wrote: > On Thu, Feb 20, 2014 at 6:29 AM, Gavin Andresen > wrote: > > I think we should get Pieter's proposal done and implemented quickly. I > > agree with Mike, it doesn't have to take a long time for the core > network to > > fully support this. > > > > Getting wallets to start generating transaction.version=3 might take > years, > > but that is OK. > > Sure I'm all for doing what Pieter suggested-- it's basically the plan > we've been executing for some time already but with the version check > to make it sane to complete. > > My reserved sounding comments were relative to the proposals to do > things with nversion=1 transactions, frankly I think thats completely > insane. Though while we're on the subject of reservations, I am far > from confident that we've uncovered all the possible malleability > routes-- that list gained a new, never before discussed entry, when > Pieter was writing it a couple weeks ago. We also have no proof of > the absence of further algebraic malleability in DSA (though I think > its somewhat unlikely, a solid proof of it has been somewhat elusive). > -- -- Gavin Andresen --20cf3010ea2508051804f2d7bd17 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Great, I'm hearing rough consensus to proceed with Pie= ter's plan.

RE: far from confident on malleability r= outes:  I'm reasonably confident that we can squash malleability f= or IsStandard, SIGHASH_ALL transactions. A proper proof of DSA signature un= -malleability (or an lower bound for how much work it would be to create a = valid doppleganger signature) would be great, but I don't think it is n= ecessary to proceed.


On Thu,= Feb 20, 2014 at 9:36 AM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
On T= hu, Feb 20, 2014 at 6:29 AM, Gavin Andresen <gavinandresen@gmail.com> wrote:
> I think we should get Pieter's proposal done and implemented quick= ly. I
> agree with Mike, it doesn't have to take a long time for the core = network to
> fully support this.
>
> Getting wallets to start generating transaction.version=3D3 might take= years,
> but that is OK.

Sure I'm all for doing what Pieter suggested— it'= s basically the plan
we've been executing for some time already but with the version check to make it sane to complete.

My reserved sounding comments were relative to the proposals to do
things with nversion=3D1 transactions, frankly I think thats completely
insane. Though while we're on the subject of reservations, I am far
from confident that we've uncovered all the possible malleability
routes— that list gained a new, never before discussed entry, when Pieter was writing it a couple weeks ago.  We also have no proof of the absence of further algebraic malleability in DSA (though I think
its somewhat unlikely, a solid proof of it has been somewhat elusive).



--
--
Gavin = Andresen
--20cf3010ea2508051804f2d7bd17--