Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.223.182 as permitted sender)
	client-ip=209.85.223.182; envelope-from=pieter.wuille@gmail.com;
	helo=mail-ie0-f182.google.com; 
MIME-Version: 1.0
In-Reply-To: <CABsx9T3bf-f7VhuRMQhvce16mSent5SzUn1ZbwpbnWAvvU6S8Q@mail.gmail.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>
	<CANEZrP26U3BjEi66xjD9SRxrAupGmYC6mKiYYw27BH3q1b1hLQ@mail.gmail.com>
	<CAAS2fgSm9o-Xz4i0_wPGPfh_108ttnNPkXtxv5hCj9CsJh=AXQ@mail.gmail.com>
	<CABsx9T1R+2rBa1VkaJiS3ktAgoMaBHfkUb3kXxwpHSxjtqNrRw@mail.gmail.com>
	<CAAS2fgTBxSfpuANP0+J1UM2nWOxQASYFBCQFW1D5L2j3DWRx-A@mail.gmail.com>
	<CABsx9T3bf-f7VhuRMQhvce16mSent5SzUn1ZbwpbnWAvvU6S8Q@mail.gmail.com>
Date: Thu, 20 Feb 2014 16:11:27 +0100
Message-ID: <CAPg+sBhdOdR=BeDKo47C1qr7R7i38VfYT5LfNijbby8CRPTqng@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with
	malleability
Precedence: list

I hereby request a BIP number.


On Thu, Feb 20, 2014 at 3:58 PM, Gavin Andresen <gavinandresen@gmail.com> wrote:
> 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 <gmaxwell@gmail.com> wrote:
>>
>> On Thu, Feb 20, 2014 at 6:29 AM, Gavin Andresen <gavinandresen@gmail.com>
>> 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
>
> ------------------------------------------------------------------------------
> 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
>