Re: [Bitcoin-development] MtGox blames bitcoin

[naman naman <namanhd@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1910 bytes --]

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 <gmaxwell@gmail.com> 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=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.
>

[-- Attachment #2: Type: text/html, Size: 3070 bytes --]