MtGox blames bitcoin

MtGox blames bitcoin
2014-02-10 11:54 ` sickpig
                   ` (2 more replies)
  
From: Drak @ 2014-02-10 11:28 UTC (permalink / raw)
  To: Bitcoin Dev

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

What is the official response from the Bitcoin Core developers about
MtGox's assertion that their problems are due to a fault of bitcoin, as
opposed to a fault of their own?

The technical analysis preluding this mess, was that MtGox was at fault for
their faulty wallet implementation.

Drak

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

 permalink raw reply	[|nested]
2014-02-10 11:54 ` 
                   ` 
  
From: Drak @ 2014-02-10 11:28 UTC (permalink / raw)
  To: Bitcoin Dev

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

What is the official response from the Bitcoin Core developers about
MtGox's assertion that their problems are due to a fault of bitcoin, as
opposed to a fault of their own?

The technical analysis preluding this mess, was that MtGox was at fault for
their faulty wallet implementation.

Drak

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

 permalink raw reply	[|nested]
2014-02-10 11:28 [Bitcoin-development] MtGox blames bitcoin Drak
  2014-02-10 11:54 ` sickpig

  2014-02-10 14:40 ` Isidor Zeuner
  
From: Gregory Maxwell @ 2014-02-10 12:25 UTC (permalink / raw)
  To: Drak;  Bitcoin Dev

On Mon, Feb 10, 2014 at 3:28 AM, Drak <drak@zikula•org> wrote:
> What is the official response from the Bitcoin Core developers about MtGox's
> assertion that their problems are due to a fault of bitcoin, as opposed to a
> fault of their own?
>
> The technical analysis preluding this mess, was that MtGox was at fault for
> their faulty wallet implementation.

In the real world fault seldom falls in a single place. Bitcoin is at
fault— in many places— for making it harder for implementers to get
things right.   MtGox is at fault for not implementing in a way that
copes with behaviors in the Bitcoin protocol which have been known
since at least 2011.
(https://en.bitcoin.it/wiki/Transaction_Malleability).

Not that Bitcoin-QT handles Malleability fantastically— but because it
tracks inputs it will still detect the mutant transactions.

An interesting point which I haven't pointed out elsewhere is that for
the question of basic funds safety in re-issuing a transaction
mallablity is basically irrelevant.

Say you pay someone and it doesn't go through (or it does and you
don't see it because its been mutated and your software can't detect
that), and they ask you to reissue.... if you reissue without
double-spending any of the original inputs you are at risk of getting
robbed. This is true with or without malleability.  Without the
double-spend of at least one input the original transaction could just
go through in addition to your reissue.

Say that you do make sure to double spend at least one input—  then
the result is funds safe safe, regardless of if a mutation happened.

Say you want to support _canceling_ a payment (send me the goat
instead!) rather than reissue you still must double-spend the
attempted payment to cancel it, since it still might go through if you
don't.  And the double spend works to protect this case regardless of
if the transaction was mutated.

For support and accounting purposes you absolutely do need tools to
identify mutated transactions, so long as mutation exists... so we
ought to provide some better tools there.  But I can't think a case
where mutation handling is necessary or sufficient for cancellation
security, but— rather— input tracking appears to be both necessary and
sufficient in all cancellation cases.

This helps explain why Bitcoin-QT— whos mutation handling kinda
stinks— doesn't ever end up in a really bad situation with mutants: it
tracks inputs pretty well.

In any case, I've always been happy to help out Mtgox with technical
issues. Having some specs for a stable transaction ID would probably
be helpful to many applications, even if it isn't the critical key you
need for cancellation security.  Removing mallability entirely has
been a soft long term goal, and there were recently (as in today) some
posts about it— look at the list archives... though it won't happen
fast since all signers/wallets will need to be updated.



 permalink raw reply	[|nested]
2014-02-10 11:28 [Bitcoin-development] MtGox blames bitcoin Drak
  2014-02-10 11:54 ` sickpig
  2014-02-10 12:25 ` Gregory Maxwell

  2014-02-10 16:30   ` Troy Benjegerdes
  2014-02-10 16:49   ` Drak
  
From: Isidor Zeuner @ 2014-02-10 14:40 UTC (permalink / raw)
  To: Bitcoin Dev

>
> What is the official response from the Bitcoin Core developers about
> MtGox's assertion that their problems are due to a fault of bitcoin, as
> opposed to a fault of their own?
>
> The technical analysis preluding this mess, was that MtGox was at fault for
> their faulty wallet implementation.
>

I'm not a core developer, but I would certainly hope that those
who have commit access to the Bitcoin repository don't let
themselves be pressured by a company holding back user funds in order
to get a patch included into the Bitcoin source code.

I think this is less a matter of whose fault it is if a company
running a custom wallet implementation has problems peering with a
network mostly running another, community-based wallet
implementation. It is a matter of common sense that it's just not
practical to try to quickly apply an update to a distributed network,
which may possibly cause problems with peering and consensus
finding. When working with a protocol based on mutual agreement of a
large user base, a single entity like MtGox would be better off trying
to have their preferred changes implemented slowly if at all, while
solving their immediate issues on their side. Problems with
transactions being accepted can often be solved by changing the wallet
client's way of peering with other nodes, without changing the
protocol at all.

Thinking this further, I am kind of surprised that something like this
can even become an issue worth discussing. I never heard of a bank
which would try to create pressure by suspending money withdrawals
until the TCP/IP protocol is changed to match their preferences.

Best regards,

Isidor Zeuner



 permalink raw reply	[|nested]
2014-02-10 14:40 ` Isidor Zeuner

  2014-02-10 16:45     ` Gregory Maxwell
  2014-02-10 16:49   ` Drak
  
From: Troy Benjegerdes @ 2014-02-10 16:30 UTC (permalink / raw)
  To: Isidor Zeuner;  Bitcoin Dev

On Mon, Feb 10, 2014 at 03:40:03PM +0100, Isidor Zeuner wrote:
> >
> > What is the official response from the Bitcoin Core developers about
> > MtGox's assertion that their problems are due to a fault of bitcoin, as
> > opposed to a fault of their own?
> >
> > The technical analysis preluding this mess, was that MtGox was at fault for
> > their faulty wallet implementation.
> >
> 
> I'm not a core developer, but I would certainly hope that those
> who have commit access to the Bitcoin repository don't let
> themselves be pressured by a company holding back user funds in order
> to get a patch included into the Bitcoin source code.

This isn't about developers.

This is about venture capitalists taking lots of money from unsuspecting
investors, and MtGox is in a psy-ops PR-war with multiple other exchanges
and lots of places that would like to take their market share and money.

Why do you want the 'official' PR-spin-war response approved by the official
bitcoin developer PR-firm, who's probably being paid by competitors to MtGox?

Name me one single person with commit access to the bitcoin github repository
who is *independent* of any venture capital or other 'investment' connections.

Fortunately for the rest of us, any dumb farmer can create a copycatcoin

Hell, if MtGox hosted their *own* fork of bitcoin I'd run that in a heartbeat.


And for full disclosure, I am available for consulting if anyone would like 
assistance setting up and hosting an independent source code repository that
includes good automated regression tests.


-- Troy



 permalink raw reply	[|nested]
2014-02-10 16:30   ` Troy Benjegerdes

  2014-02-10 18:25       ` Troy Benjegerdes
  
From: Gregory Maxwell @ 2014-02-10 16:45 UTC (permalink / raw)
  To: Troy Benjegerdes;  Isidor Zeuner

On Mon, Feb 10, 2014 at 8:30 AM, Troy Benjegerdes <hozer@hozed•org> wrote:
> Name me one single person with commit access to the bitcoin github repository
> who is *independent* of any venture capital or other 'investment' connections.

I am, unless you count the fact that I own some Bitcoin and some
mining hardware as "'investment' connections" (and that case your
comments are worthless).

(By not naming anyone else I don't mean to imply there are no others,
but I don't want to speak for anyone else. Nor would I necessarily
expect the other part(ies|y) to step forward, since this mostly
appears to be an invitation to step up and be attacked.)



 permalink raw reply	[|nested]
2014-02-10 14:40 ` Isidor Zeuner
  2014-02-10 16:30   ` Troy Benjegerdes

  
From: Drak @ 2014-02-10 16:49 UTC ( / )
  To: Isidor Zeuner



Well done Gavin for quickly setting the record straight[1] officially as
project lead. MtGox tried to blame their issues by throwing Bitcoin under a
bus and I am glad there has been a public rebuttal showing up their
incompetence which is doing harm to the bitcoin eco system. Basically, yes
there are issues, but MtGox should have worked around it.

Also thanks to Gregory for also writing[2] about the matter.

Drak

[1] https://bitcoinfoundation.org/blog/?p=418
[2]
http://www.cryptocoinsnews.com/2014/02/10/mt-gox-blames-bitcoin-core-developer-greg-maxwell-responds/
2014-02-10 16:45     ` Gregory Maxwell

  2014-02-10 18:45         ` Jameson Lopp
  
From: Troy Benjegerdes @ 2014-02-10 18:25 UTC (permalink / raw)
  To: Gregory Maxwell;  bitcoin-development

On Mon, Feb 10, 2014 at 08:45:03AM -0800, Gregory Maxwell wrote:
> On Mon, Feb 10, 2014 at 8:30 AM, Troy Benjegerdes <hozer@hozed•org> wrote:
> > Name me one single person with commit access to the bitcoin github repository
> > who is *independent* of any venture capital or other 'investment' connections.
> 
> I am, unless you count the fact that I own some Bitcoin and some
> mining hardware as "'investment' connections" (and that case your
> comments are worthless).
> 
> (By not naming anyone else I don't mean to imply there are no others,
> but I don't want to speak for anyone else. Nor would I necessarily
> expect the other part(ies|y) to step forward, since this mostly
> appears to be an invitation to step up and be attacked.)

Thank you.

I also appreciate your commentary[1], and willingness to list your investment
position. What I'm concerned about are people who have signed non-disclosure 
agreements or who's salary/equity/whatever depend on people who are experts
at manipulating markets to take naive investors money.

Independent is also a state of mind as much as it is about financial connections.

What pisses me off here is that a huge amount of wealth just changed hands based
on MtGox's press release, and it stinks of insider trading. I still maintain the
best outcome would be for MtGox to AGPLv3 release their code, and then those of 
us that understand it would be able to have a public technical discussion about
how to fix it, and MtGox would still maintain their intellectual property
ownership position.

This, however, cuts off a significant revenue stream for people who take money
making market bets 5 minutes before the information goes public, so I expect
the likelyhood of such an outbreak of sanity is quite low.

[1] http://www.cryptocoinsnews.com/2014/02/10/mt-gox-blames-bitcoin-core-developer-greg-maxwell-responds/


DISCLAIMER: I have a significant emotional investment in copyleft/viral copyright
development models, and I expect to take a lot of money charging people to write
code I give away for free. I also occasionally make money from cryptocurrency
mining, but only when I can sell it in functional and transparent markets.



 permalink raw reply	[|nested]
2014-02-10 18:25       ` Troy Benjegerdes

  2014-02-10 18:53           ` Gavin Andresen
  2014-02-10 19:07           ` Troy Benjegerdes
  
From: Jameson Lopp @ 2014-02-10 18:45 UTC (permalink / raw)
  To: bitcoin-development

You have plenty of good points, but they are not relevant to this mailing list. I suggest you take them elsewhere.
--
Jameson Lopp
Software Engineer
Bronto Software, Inc

On 02/10/2014 01:25 PM, Troy Benjegerdes wrote:
> On Mon, Feb 10, 2014 at 08:45:03AM -0800, Gregory Maxwell wrote:
>> On Mon, Feb 10, 2014 at 8:30 AM, Troy Benjegerdes <hozer@hozed•org> wrote:
>>> Name me one single person with commit access to the bitcoin github repository
>>> who is *independent* of any venture capital or other 'investment' connections.
>>
>> I am, unless you count the fact that I own some Bitcoin and some
>> mining hardware as "'investment' connections" (and that case your
>> comments are worthless).
>>
>> (By not naming anyone else I don't mean to imply there are no others,
>> but I don't want to speak for anyone else. Nor would I necessarily
>> expect the other part(ies|y) to step forward, since this mostly
>> appears to be an invitation to step up and be attacked.)
> 
> Thank you.
> 
> I also appreciate your commentary[1], and willingness to list your investment
> position. What I'm concerned about are people who have signed non-disclosure 
> agreements or who's salary/equity/whatever depend on people who are experts
> at manipulating markets to take naive investors money.
> 
> Independent is also a state of mind as much as it is about financial connections.
> 
> What pisses me off here is that a huge amount of wealth just changed hands based
> on MtGox's press release, and it stinks of insider trading. I still maintain the
> best outcome would be for MtGox to AGPLv3 release their code, and then those of 
> us that understand it would be able to have a public technical discussion about
> how to fix it, and MtGox would still maintain their intellectual property
> ownership position.
> 
> This, however, cuts off a significant revenue stream for people who take money
> making market bets 5 minutes before the information goes public, so I expect
> the likelyhood of such an outbreak of sanity is quite low.
> 
> [1] http://www.cryptocoinsnews.com/2014/02/10/mt-gox-blames-bitcoin-core-developer-greg-maxwell-responds/
> 
> 
> DISCLAIMER: I have a significant emotional investment in copyleft/viral copyright
> development models, and I expect to take a lot of money charging people to write
> code I give away for free. I also occasionally make money from cryptocurrency
> mining, but only when I can sell it in functional and transparent markets.
> 
> ------------------------------------------------------------------------------
> Android&trade; apps run on BlackBerry&reg;10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience.  Start now.
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 



 permalink raw reply	[|nested]
2014-02-10 18:45         ` Jameson Lopp

  2014-02-10 19:07           ` Troy Benjegerdes
  
From: Gavin Andresen @ 2014-02-10 18:53 UTC (permalink / raw)
  To: Jameson Lopp;  Bitcoin Dev

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

RE: taking discussion elsewhere:

Yes, please, the purpose of this mailing list is technical discussions to
encourage interoperability of Bitcoin implementations, improve ease-of-use
and security, etc.

-- 
--
Gavin Andresen

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

 permalink raw reply	[|nested]
2014-02-10 18:45         ` Jameson Lopp
  2014-02-10 18:53           ` Gavin Andresen

  2014-02-10 19:23             ` Peter Todd
  
From: Troy Benjegerdes @ 2014-02-10 19:07 UTC (permalink / raw)
  To: Jameson Lopp;  bitcoin-development

If you've got any ideas for a better forum, let me know.

MtGox is one of the largest public faces of the code being developed here. If
the public perception is that this is a bitcoin protocol flaw, then we need
some damned strong and compelling public arguments about why it ain't so. But
after some thought, that's not the critical issue I want to raise on this list.

If something about the implementation, the protocol, of bitcoin-qt or bitcoind
makes it easy for an attacker to mutate transactions and hard for an 'end-user'
such as MtGox to confirm payments, then we've got a fundamental user-interface
flaw.

We can get all indignant about RTFM or telling the users they are idiots, but
that's not really going to be good for long-term adoption and use.

My opinion is part of the development process should be to react to public
perceptions of how the code is being used (and mis-used), and how the market is
being manipulated, and try to improve it so the whole system is stable,
predictable, and friendly to users.


On Mon, Feb 10, 2014 at 01:45:58PM -0500, Jameson Lopp wrote:
> You have plenty of good points, but they are not relevant to this mailing list. I suggest you take them elsewhere.
> --
> Jameson Lopp
> Software Engineer
> Bronto Software, Inc
> 
> On 02/10/2014 01:25 PM, Troy Benjegerdes wrote:
> > On Mon, Feb 10, 2014 at 08:45:03AM -0800, Gregory Maxwell wrote:
> >> On Mon, Feb 10, 2014 at 8:30 AM, Troy Benjegerdes <hozer@hozed•org> wrote:
> >>> Name me one single person with commit access to the bitcoin github repository
> >>> who is *independent* of any venture capital or other 'investment' connections.
> >>
> >> I am, unless you count the fact that I own some Bitcoin and some
> >> mining hardware as "'investment' connections" (and that case your
> >> comments are worthless).
> >>
> >> (By not naming anyone else I don't mean to imply there are no others,
> >> but I don't want to speak for anyone else. Nor would I necessarily
> >> expect the other part(ies|y) to step forward, since this mostly
> >> appears to be an invitation to step up and be attacked.)
> > 
> > Thank you.
> > 
> > I also appreciate your commentary[1], and willingness to list your investment
> > position. What I'm concerned about are people who have signed non-disclosure 
> > agreements or who's salary/equity/whatever depend on people who are experts
> > at manipulating markets to take naive investors money.
> > 
> > Independent is also a state of mind as much as it is about financial connections.
> > 
> > What pisses me off here is that a huge amount of wealth just changed hands based
> > on MtGox's press release, and it stinks of insider trading. I still maintain the
> > best outcome would be for MtGox to AGPLv3 release their code, and then those of 
> > us that understand it would be able to have a public technical discussion about
> > how to fix it, and MtGox would still maintain their intellectual property
> > ownership position.
> > 
> > This, however, cuts off a significant revenue stream for people who take money
> > making market bets 5 minutes before the information goes public, so I expect
> > the likelyhood of such an outbreak of sanity is quite low.
> > 
> > [1] http://www.cryptocoinsnews.com/2014/02/10/mt-gox-blames-bitcoin-core-developer-greg-maxwell-responds/
> > 
> > 
> > DISCLAIMER: I have a significant emotional investment in copyleft/viral copyright
> > development models, and I expect to take a lot of money charging people to write
> > code I give away for free. I also occasionally make money from cryptocurrency
> > mining, but only when I can sell it in functional and transparent markets.
> > 
> > ------------------------------------------------------------------------------
> > Android&trade; apps run on BlackBerry&reg;10
> > Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> > Now with support for Jelly Bean, Bluetooth, Mapview and more.
> > Get your Android app in front of a whole new audience.  Start now.
> > http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists•sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> > 
> 
> ------------------------------------------------------------------------------
> Androi apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience.  Start now.
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development



 permalink raw reply	[|nested]
2014-02-10 19:07           ` Troy Benjegerdes

  2014-02-10 19:30               ` naman naman
  
From: Peter Todd @ 2014-02-10 19:23 UTC (permalink / raw)
  To: Troy Benjegerdes;  bitcoin-development

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

On Mon, Feb 10, 2014 at 01:07:03PM -0600, Troy Benjegerdes wrote:
> If you've got any ideas for a better forum, let me know.

Your political conversations would be welcome at unsystem@lists•dyne.org

See you there.

-- 
'peter'[:-1]@petertodd.org
0000000077ddbd0b6faa6d6fe50cdc7808dea5db5b538f85b736ede8515c54c7

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

 permalink raw reply	[|nested]
2014-02-10 19:23             ` Peter Todd

  2014-02-10 19:40                 ` Peter Todd
  
From: naman naman @ 2014-02-10 19:30 UTC (permalink / raw)
  To: Peter Todd;  bitcoin-development

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

Hi guys,

Please check this thread
https://bitcointalk.org/index.php?topic=458608.0for a possible attack
scenario.

Already mailed Gavin, Mike Hearn and Adam about this :

See if it makes sense.


On Tue, Feb 11, 2014 at 12:53 AM, Peter Todd <pete@petertodd•org> wrote:

> On Mon, Feb 10, 2014 at 01:07:03PM -0600, Troy Benjegerdes wrote:
> > If you've got any ideas for a better forum, let me know.
>
> Your political conversations would be welcome at unsystem@lists•dyne.org
>
> See you there.
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000077ddbd0b6faa6d6fe50cdc7808dea5db5b538f85b736ede8515c54c7
>
>
> ------------------------------------------------------------------------------
> Androi apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience.  Start now.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

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

 permalink raw reply	[|nested]
2014-02-10 19:30               ` naman naman

       [not found]                   ` <52F9377D.9010405@gmail.com>
  
From: Peter Todd @ 2014-02-10 19:40 UTC (permalink / raw)
  To: naman naman;  bitcoin-development

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

On Tue, Feb 11, 2014 at 01:00:21AM +0530, naman naman wrote:
> Hi guys,
> 
> Please check this thread
> https://bitcointalk.org/index.php?topic=458608.0for a possible attack
> scenario.
> 
> Already mailed Gavin, Mike Hearn and Adam about this :
> 
> See if it makes sense.

That's basically what appears to have happened with Mt. Gox.

Preventing the attack is as simple as training your customer service
people to ask the customer if their wallet software shows a payment to a
specific address of a specific amount at some approximate time. Making
exact payment amounts unique - add a few satoshis - is a trivial if
slightly ugly way of making sure payments can be identified uniquely
over the phone. That the procedure at Mt. Gox let front-line customer
service reps manually send funds to customers without a proper
investigation of why the funds didn't arrive was a serious mistake on
their part.

Ultimately this is more of a social engineering attack than a technical
one, and a good example of why well-thought-out payment protocols are
helpful. Though the BIP70 payment protocol doesn't yet handle busines to
individual, or individual to indivudal, payments a future iteration can
and this kind of problem will be less of an issue.

Similarly stealth addresses have an inherent per-tx unique identifier,
the derived pubkey, which a UI might be able to take advantage of.

-- 
'peter'[:-1]@petertodd.org
0000000076654614e7bf72ac80d47c57bca12503989f4d602538d3cd7892ca7d

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

 permalink raw reply	[|nested]
[not found]                   ` <52F9377D.9010405@gmail.com>

  2014-02-11 20:49                       ` Gregory Maxwell
  
From: naman naman @ 2014-02-11 20:42 UTC (permalink / raw)
  To: Vocatus Gate;  bitcoin-development

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

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).

Today they are apparently at work here
https://github.com/bitcoin/bitcoin/pull/3651

Amazing how nobody acknowledges it until later when the attack already
happens. The devs need to show some greater level of responsibility.

Don't get me wrong - I am not trying to claim credit for the attack scheme
described (though I do not know of any other place where this was mentioned
earlier as an attack scheme), but I am trying to make the point that people
should just be around and at least make others feel that their concerns are
being read. Now putting this on some place like reddit will only give the
community a bad name.

On a lighter note I messaged some of the devs (as my previous mail says)
saying the attack should be called "thenoblebot" attack (after my handle,
which would inspire me to pursue crypto studies further). It was meant to
be a lame joke. But I had no idea how it would start causing so much
disruption in the ecosystem.

Regards
thenoblebot


On Tue, Feb 11, 2014 at 2:03 AM, Vocatus Gate <vocatus.gate@gmail•com>wrote:

>  It's quite simple, really:
>
> Unique transaction == (Inputs+Outputs+ReceivingAddress)
>
> Problem solved. Simply don't rely on TxID for tracking. Can we put this
> issue to rest and move on?
>
>
>
>
> On 2014-02-10 12:40 PM, Peter Todd wrote:
>
> On Tue, Feb 11, 2014 at 01:00:21AM +0530, naman naman wrote:
>
>  Hi guys,
>
> Please check this threadhttps://bitcointalk.org/index.php?topic=458608.0for a possible attack
> scenario.
>
> Already mailed Gavin, Mike Hearn and Adam about this :
>
> See if it makes sense.
>
>  That's basically what appears to have happened with Mt. Gox.
>
> Preventing the attack is as simple as training your customer service
> people to ask the customer if their wallet software shows a payment to a
> specific address of a specific amount at some approximate time. Making
> exact payment amounts unique - add a few satoshis - is a trivial if
> slightly ugly way of making sure payments can be identified uniquely
> over the phone. That the procedure at Mt. Gox let front-line customer
> service reps manually send funds to customers without a proper
> investigation of why the funds didn't arrive was a serious mistake on
> their part.
>
> Ultimately this is more of a social engineering attack than a technical
> one, and a good example of why well-thought-out payment protocols are
> helpful. Though the BIP70 payment protocol doesn't yet handle busines to
> individual, or individual to indivudal, payments a future iteration can
> and this kind of problem will be less of an issue.
>
> Similarly stealth addresses have an inherent per-tx unique identifier,
> the derived pubkey, which a UI might be able to take advantage of.
>
>
>
>
> ------------------------------------------------------------------------------
> Androi apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience.  Start now.http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Bitcoin-development mailing listBitcoin-development@lists•sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>

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

 permalink raw reply	[|nested]
2014-02-11 20:42                     ` naman naman

  2014-02-11 20:56                         ` naman naman
  
From: Gregory Maxwell @ 2014-02-11 20:49 UTC (permalink / raw)
  To: naman naman;  Bitcoin Development, Vocatus Gate

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.



 permalink raw reply	[|nested]
2014-02-11 20:49                       ` Gregory Maxwell

  2014-02-13 12:20                           ` naman naman
  
From: naman naman @ 2014-02-11 20:56 UTC (permalink / raw)
  To: Gregory Maxwell;  Bitcoin Development, Vocatus Gate

[-- 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 --]

 permalink raw reply	[|nested]
2014-02-11 20:56                         ` naman naman

  
From: naman naman @ 2014-02-13 12:20 UTC (permalink / raw)
  To: Gregory Maxwell;  Bitcoin Development, Vocatus Gate

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

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 <namanhd@gmail•com> 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 <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#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.
>>
>
>

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

 permalink raw reply	[|nested]