From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WDvHq-0006u5-Bq for bitcoin-development@lists.sourceforge.net; Thu, 13 Feb 2014 12:21:02 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.54 as permitted sender) client-ip=209.85.212.54; envelope-from=namanhd@gmail.com; helo=mail-vb0-f54.google.com; Received: from mail-vb0-f54.google.com ([209.85.212.54]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WDvHp-0006S1-3M for bitcoin-development@lists.sourceforge.net; Thu, 13 Feb 2014 12:21:02 +0000 Received: by mail-vb0-f54.google.com with SMTP id w20so8167512vbb.13 for ; Thu, 13 Feb 2014 04:20:55 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.58.169.7 with SMTP id aa7mr805474vec.24.1392294055560; Thu, 13 Feb 2014 04:20:55 -0800 (PST) Received: by 10.221.49.8 with HTTP; Thu, 13 Feb 2014 04:20:55 -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: Thu, 13 Feb 2014 17:50:55 +0530 Message-ID: From: naman naman To: Gregory Maxwell Content-Type: multipart/alternative; boundary=047d7b6dcf429acdb204f248b8b0 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: 1WDvHp-0006S1-3M 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: Thu, 13 Feb 2014 12:21:02 -0000 --047d7b6dcf429acdb204f248b8b0 Content-Type: text/plain; charset=ISO-8859-1 Hi guys, I with all thats happening now I think (yea no hard proof) most of it is being done on purpose (transaction mutation) by some pool/entity. I have posted here https://bitcointalk.org/index.php?topic=463350.0 of how to go about finding out if its some pool doing it. This does in no way solve "fix" the malleability issue BUT IMHO it might help "alleviate" the problem we are facing at a network level. Please have a look if possible. Kind Regards, thenoblebot On Wed, Feb 12, 2014 at 2:26 AM, naman naman wrote: > 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#msg5063789but >> > 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. >> > > --047d7b6dcf429acdb204f248b8b0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi guys,

I with all thats happening now I thi= nk (yea no hard proof) most of it is being done on purpose (transaction mut= ation) by some pool/entity.
I have posted here=A0https://bitcointalk.org/inde= x.php?topic=3D463350.0 of how to go about finding out if its some pool = doing it. This does in no way solve "fix" the malleability issue = BUT IMHO it might help "alleviate" the problem we are facing at a= network level.
Please have a look if possible.

Kind Regards,=
thenoblebot


=
On Wed, Feb 12, 2014 at 2:26 AM, naman naman <n= amanhd@gmail.com> wrote:
Gregory Maxwell says : &quo= t;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 w= hy your resorting to such an adhominem. But I have already said that you we= re 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 tha= t leaves a whole lot of businesses in the lurch who have relied on txid (al= beit wrongly 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.


--047d7b6dcf429acdb204f248b8b0--