From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WDKO1-0004oB-Ue for bitcoin-development@lists.sourceforge.net; Tue, 11 Feb 2014 20:56:57 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.128.176 as permitted sender) client-ip=209.85.128.176; envelope-from=namanhd@gmail.com; helo=mail-ve0-f176.google.com; Received: from mail-ve0-f176.google.com ([209.85.128.176]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WDKO0-0002Oe-0C for bitcoin-development@lists.sourceforge.net; Tue, 11 Feb 2014 20:56:57 +0000 Received: by mail-ve0-f176.google.com with SMTP id oz11so6467691veb.7 for ; Tue, 11 Feb 2014 12:56:50 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.52.155.66 with SMTP id vu2mr674442vdb.50.1392152210394; Tue, 11 Feb 2014 12:56:50 -0800 (PST) Received: by 10.221.49.8 with HTTP; Tue, 11 Feb 2014 12:56:50 -0800 (PST) In-Reply-To: References: <20140210144003.2BDCCDDAEFC@quidecco.de> <20140210163055.GJ3180@nl.grid.coop> <20140210182506.GM3180@nl.grid.coop> <52F91E66.6060305@gmail.com> <20140210190703.GO3180@nl.grid.coop> <20140210192308.GA17359@savin> <20140210194032.GD17359@savin> <52F9377D.9010405@gmail.com> Date: Wed, 12 Feb 2014 02:26:50 +0530 Message-ID: From: naman naman To: Gregory Maxwell Content-Type: multipart/alternative; boundary=089e0160ca9ef9537504f227b1df 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 (namanhd[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: 1WDKO0-0002Oe-0C Cc: Bitcoin Development , Vocatus Gate Subject: Re: [Bitcoin-development] MtGox blames bitcoin 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: Tue, 11 Feb 2014 20:56:58 -0000 --089e0160ca9ef9537504f227b1df Content-Type: text/plain; charset=ISO-8859-1 Gregory Maxwell says : "Try paying a consultant if your ego demands that you have a technical expert to entertain your musing with immediate response." I don't know why your resorting to such an adhominem. But I have already said that you were the only one who responded. Your response was correct as is reflected in the conversation on the forums. No doubting that. But it does not address the full scope of the attack where a small pool would intentionally (or out of whatever reason) make the hash invalid for the txs they recieve. So that leaves a whole lot of businesses in the lurch who have relied on txid (albeit wrongly that) for their tracking purposes. Thats all I'm trying to say, without blaming anyone. Hope it makes sense. On Wed, Feb 12, 2014 at 2:19 AM, Gregory Maxwell wrote: > On Tue, Feb 11, 2014 at 12:42 PM, naman naman wrote: > > I was talking about a DOS attack in > > https://bitcointalk.org/index.php?topic=458608.0 (ofcourse only > applicable > > to entitys doing the tracking with txids). > > > > Amazing how I did not get a response from any of the devs (except Greg's > > response > > https://bitcointalk.org/index.php?topic=458608.msg5063789#msg5063789 but > > that too was short and not concerning the attack scenario plausibiity as > I > > replied to him). > > Try paying a consultant if your ego demands that you have a technical > expert to entertain your musing with immediate response. > > My response was absolutely relevant. > > If you reissue a transaction without respending the prior transactions > coins, you will end up double paying. Only spending the inputs in > question can prevent the prior transaction (itself or in other form) > from going through. > > Once you respend the inputs there is no risk of actually losing funds > due to an issue regardless of how you track coins in your higher level > application. > --089e0160ca9ef9537504f227b1df Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Gregory Maxwell says : "Try paying a consultant if your ego demands = that you have a technical
expert to enter= tain your musing with immediate response."

I don't know why you= r resorting to such an adhominem. But I have already said that you were the= only one who responded. Your response was correct as is reflected in the c= onversation on the forums. No doubting that. But it does not address the fu= ll scope of the attack where a small pool would intentionally (or out of wh= atever reason) make the hash invalid for the txs they recieve. So that leav= es a whole lot of businesses in the lurch who have relied on txid (albeit w= rongly that) for their tracking purposes. Thats all I'm trying to say, = without blaming anyone.=A0

Hop= e it makes sense.


On Wed, Feb 12, 2014 at 2:19 AM, Gregory Maxwell <gmaxwell@gmail.com&= gt; wrote:
On Tue, Feb 11, 2014 at 12:42 PM, naman naman <namanhd@gmail.com> wrote:
> I was talking about a DOS attack in
> https://bitcointalk.org/index.php?topic=3D458608.0 (ofcours= e only applicable
> to entitys doing the tracking with txids).
>
> Amazing how I did not get a response from any of the devs (except Greg= 's
> response
> https://bitcointalk.org/index.php?topic=3D45= 8608.msg5063789#msg5063789 but
> that too was short and not concerning the attack scenario plausibiity = as I
> replied to him).

Try paying a consultant if your ego demands that you have a technical=
expert to entertain your musing with immediate response.

My response was absolutely relevant.

If you reissue a transaction without respending the prior transactions
coins, you will end up double paying. Only spending the inputs in
question can prevent the prior transaction (itself or in other form)
from going through.

Once you respend the inputs there is no risk of actually losing funds
due to an issue regardless of how you track coins in your higher level
application.

--089e0160ca9ef9537504f227b1df--