Bitcoin Forum
October 31, 2024, 11:02:01 PM *
News: Bitcoin Pumpkin Carving Contest
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: something fishy about Gox, need some inputs here  (Read 1297 times)
mmitech (OP)
Legendary
*
Offline Offline

Activity: 1148
Merit: 1001


things you own end up owning you


View Profile
February 10, 2014, 10:05:31 PM
 #1

I feel I am missing something here, so gox halted BTC withdrawals claiming that its is the protocol fault, we all agree on the bug and it has been known for a long time now, what I cant understand is how users are effected.

ok take a moment and hear me out, or in other words try to explain to me how this works:

1- I request a BTC withdraw
2- Gox hot wallet is empty
3- now 1000 user requests BTC withdrawals.
4- gox fill up the hot wallet to make it possible to withdraw or at the mean time they get enough deposits to proceed with the withdrawals.
5- the attacker is one of those users who did request a withdraw.
6- gox send TX1.
7- attacker change the TX1 to TX2
8- everyone get their Bitcoins regardless which tx is.
9- attacker claims that he didn't receive the BTC so they check their DB for TX1 and they agree on his claim and credit his account ( but again why, what about the other 999 user).
10- all the 999 user got their bitcoins and no one complains.


if we agree on the 10 steps above, then there is something fishy here, now when I see thousands of customers complaining about not getting Bitcoin withdrawals it makes me wonder how is this possible !!? because my logic tells me the 999 user shouldn't be effected, only the attacker who can claim on being "effected".

but for the last couple of weeks some people got their bitcoins when others didn't, how do we explain this ? anyone try to explain this to me ?
bitcoinminer
Sr. Member
****
Offline Offline

Activity: 322
Merit: 252



View Profile
February 10, 2014, 10:06:29 PM
 #2

Close.

1.) People send BTC to GOXXX
2.) GOXXX Takes the BTC
3.) Nobody can withdraw

Be fearful when others are greedy, and greedy when others are fearful.

-Warren Buffett
Lauda
Legendary
*
Offline Offline

Activity: 2674
Merit: 2965


Terminated.


View Profile WWW
February 10, 2014, 10:07:52 PM
 #3

You were warned before, many times.
It's your fault for using Gox. I've always stayed away, and I was right.

"The Times 03/Jan/2009 Chancellor on brink of second bailout for banks"
😼 Bitcoin Core (onion)
mmitech (OP)
Legendary
*
Offline Offline

Activity: 1148
Merit: 1001


things you own end up owning you


View Profile
February 10, 2014, 10:09:50 PM
 #4

I have never ever used gox, I am verified and all but never tried it, I've always used Bitstamp even when they were relatively small...
Gulinborsti
Full Member
***
Offline Offline

Activity: 286
Merit: 100


View Profile
February 10, 2014, 10:11:01 PM
 #5

I feel I am missing something here, so gox halted BTC withdrawals claiming that its is the protocol fault, we all agree on the bug and it has been known for a long time now, what I cant understand is how users are effected.

ok take a moment and hear me out, or in other words try to explain to me how this works:

1- I request a BTC withdraw
2- Gox hot wallet is empty
3- now 1000 user requests BTC withdrawals.
4- gox fill up the hot wallet to make it possible to withdraw or at the mean time they get enough deposits to proceed with the withdrawals.
5- the attacker is one of those users who did request a withdraw.
6- gox send TX1.
7- attacker change the TX1 to TX2
8- everyone get their Bitcoins regardless which tx is.
9- attacker claims that he didn't receive the BTC so they check their DB for TX1 and they agree on his claim and credit his account ( but again why, what about the other 999 user).
10- all the 999 user got their bitcoins and no one complains.


if we agree on the 10 steps above, then there is something fishy here, now when I see thousands of customers complaining about not getting Bitcoin withdrawals it makes me wonder how is this possible !!? because my logic tells me the 999 user shouldn't be effected, only the attacker who can claim on being "effected".

but for the last couple of weeks some people got their bitcoins when others didn't, how do we explain this ? anyone try to explain this to me ?

This http://www.reddit.com/r/Bitcoin/comments/1x93tf/some_irc_chatter_about_what_is_going_on_at_mtgox/cf99yac explains the situation pretty well ...
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1079


Gerald Davis


View Profile
February 10, 2014, 10:15:49 PM
 #6

I feel I am missing something here, so gox halted BTC withdrawals claiming that its is the protocol fault, we all agree on the bug and it has been known for a long time now, what I cant understand is how users are effected.

ok take a moment and hear me out, or in other words try to explain to me how this works:

1- I request a BTC withdraw
2- Gox hot wallet is empty
3- now 1000 user requests BTC withdrawals.
4- gox fill up the hot wallet to make it possible to withdraw or at the mean time they get enough deposits to proceed with the withdrawals.
5- the attacker is one of those users who did request a withdraw.
6- gox send TX1.
7- attacker change the TX1 to TX2
8- everyone get their Bitcoins regardless which tx is.
9- attacker claims that he didn't receive the BTC so they check their DB for TX1 and they agree on his claim and credit his account ( but again why, what about the other 999 user).
10- all the 999 user got their bitcoins and no one complains.


if we agree on the 10 steps above, then there is something fishy here, now when I see thousands of customers complaining about not getting Bitcoin withdrawals it makes me wonder how is this possible !!? because my logic tells me the 999 user shouldn't be effected, only the attacker who can claim on being "effected".

but for the last couple of weeks some people got their bitcoins when others didn't, how do we explain this ? anyone try to explain this to me ?

MtGox had other issues which resulted in payments failing, being delayed, and needing to be resent.  The attackers took advantage of this to "camouflage" their actions.  Your right if you send out payments to 50,000 users and 49,999 report no issue but one user over and over reports not getting paid well then "hmm maybe this user is running a scam" however if you send payments to 50,000 users and 30,000 of them report non-payment due to a variety of reasons (caused by Gox) then it becomes easier for the attacker to hide.

MtGox wrote their own client, and they did so horribly bad.   Their client isn't worthy of being used by a hobbyist experimenting on testnet but they used it in production for a systme involving millions of dollars of assets.  We have no idea how many things they got wrong but looking at the failed transaction we know at a minimum these things were wrong:

a) MtGox double spent their own coins.
b) MtGox paid insufficient fees on tx which were low priority meaning they would not be relayed to miners by most nodes.
c) MtGox created tx which violated the "anti-spam" rules which caused tx to be dropped (not relayed) by some nodes.
d) MtGox attempted to spend immature newly mined coins (newly mined coins can't be spent for 120 blocks).
e) MtGox used non-canonical signatures on transactions which were rejected by newer nodes.

and

f) MtGox failed to account for mutable hashes.


Now if MtGox had done a through e they wouldn't have lost any coins.  Yes users would be delayed.  Yes it would make them look foolish but had they at least done f right they would have not paid attackers twice.

On the other had if MtGox had done a through e right but messed up f, then your scenario in the OP would be correct.  Legit users would have seen no issue, attackers would have gotten double paid.

However MtGox managed to get a through f wrong so legit users were affected AND attackers were able to trick them into making double payments.   Worse the two issues compound on each other.  If the attackers were the only ones reporting non-payment then it is likely MtGox would have gotten suspicious relatively quickly however since this has been going on for the better part of a month and involves tens of thousands of transactions who knows how many times attackers were able to get away with a double payment.


Moral of the story, a custom bitcoin client must be exactly compliant with other nodes on the network.  "Kinda good, most of the time" is not sufficient.  It is an undertaking that most people should not attempt.  I consider myself moderately knowledgeable about bitcoin, and I don't use a custom bitcoin client.  I use a custom backend which communicates with the reference client (i.e. bitcoind) for these exact reasons.   MtGox's attempt to build a custom client would be laughably bad if released as an open source alternative client with a warning to be used for testing only.  The fact that it was used as a closed source production client borders on criminal negligence.
mmitech (OP)
Legendary
*
Offline Offline

Activity: 1148
Merit: 1001


things you own end up owning you


View Profile
February 10, 2014, 10:23:05 PM
 #7

I feel I am missing something here, so gox halted BTC withdrawals claiming that its is the protocol fault, we all agree on the bug and it has been known for a long time now, what I cant understand is how users are effected.

ok take a moment and hear me out, or in other words try to explain to me how this works:

1- I request a BTC withdraw
2- Gox hot wallet is empty
3- now 1000 user requests BTC withdrawals.
4- gox fill up the hot wallet to make it possible to withdraw or at the mean time they get enough deposits to proceed with the withdrawals.
5- the attacker is one of those users who did request a withdraw.
6- gox send TX1.
7- attacker change the TX1 to TX2
8- everyone get their Bitcoins regardless which tx is.
9- attacker claims that he didn't receive the BTC so they check their DB for TX1 and they agree on his claim and credit his account ( but again why, what about the other 999 user).
10- all the 999 user got their bitcoins and no one complains.


if we agree on the 10 steps above, then there is something fishy here, now when I see thousands of customers complaining about not getting Bitcoin withdrawals it makes me wonder how is this possible !!? because my logic tells me the 999 user shouldn't be effected, only the attacker who can claim on being "effected".

but for the last couple of weeks some people got their bitcoins when others didn't, how do we explain this ? anyone try to explain this to me ?

MtGox had other issues which resulted in payments failing, being delayed, and needing to be resent.  The attackers took advantage of this to "camouflage" their actions.  Your right if you send out payments to 50,000 users and 49,999 report no issue but one user over and over reports not getting paid well then "hmm maybe this user is running a scam" however if you send payments to 50,000 users and 30,000 of them report non-payment due to a variety of reasons (caused by Gox) then it becomes easier for the attacker to hide.

MtGox wrote their own client, and they did so horribly bad.   Their client isn't worthy of being used by a hobbyist experimenting on testnet but they used it in production for a systme involving millions of dollars of assets.  We have no idea how many things they got wrong but looking at the failed transaction we know at a minimum these things were wrong:

a) MtGox double spent their own coins.
b) MtGox paid insufficient fees on tx which were low priority meaning they would not be relayed to miners by most nodes.
c) MtGox created tx which violated the "anti-spam" rules which caused tx to be dropped (not relayed) by some nodes.
d) MtGox attempted to spend immature newly mined coins (newly mined coins can't be spent for 120 blocks).
e) MtGox used non-canonical signatures on transactions which were rejected by newer nodes.

Moral of the story, a custom bitcoin client must be EXACTLY compliant with other nodes on the network.  "Kinda good, most of the time" is not sufficient.  It is an undertaking that most people should not attempt.  I consider myself moderately knowledgeable about bitcoin and I don't use a customer client.  I use a custom backend which communicates with the reference client for these exact reasons.   MtGox attempt would be laughably bad is released as an open source alternative client, the fact that it was used as a closed source production client borders on criminal negligence.


ok got it, but supposedly we will fix the Malleability issue today, how will this fix all their issues ? they will still have ton of other issues on their side, this is what I really don't get, do they take us for idiots ?
bitcoinminer
Sr. Member
****
Offline Offline

Activity: 322
Merit: 252



View Profile
February 10, 2014, 10:25:15 PM
 #8


ok got it, but supposedly we will fix the Malleability issue today, how will this fix all their issues ? they will still have ton of other issues on their side, this is what I really don't get, do they take us for idiots ?

Yes.  And all of their customers keep proving them correct, again, and again, and again, and again...

Be fearful when others are greedy, and greedy when others are fearful.

-Warren Buffett
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1079


Gerald Davis


View Profile
February 10, 2014, 10:28:28 PM
 #9

ok got it, but supposedly we will fix the Malleability issue today, how will this fix all their issues ?

It won't and it won't be "fixed".  It is a limitation of the system that we have to deal with.  The reference client does a good job of handling it.  Those who can't do a better job shouldn't attempt to do so.  Even if it was going to be "fixed" by a hard fork that would be months if not years.  From proposal to final release P2SH took 10+ months.  This would be a much more radical change to the core protocol.  IMHO it will NEVER happen but if it did, do you honestly think MtGox just holding on to the coins for 10 months is a viable solution?  With a small amount of competence malleability can be detected.

Quote
they will still have ton of other issues on their side, this is what I really don't get, do they take us for idiots ?

I don't what they take "us" for but yes this wouldn't affect the half dozen other critical flaws in the client.  It also won't "undo" the unknown number of bitcoins they double paid to attackers.
vpitcher07
Sr. Member
****
Offline Offline

Activity: 342
Merit: 250


View Profile
February 10, 2014, 10:32:52 PM
 #10

Someone explain something to me. Why would the attackers do this knowing that they would cause the price to tank? If it causes BTC to be worthless then they're also SOL. Maybe they didn't think they would get caught somehow? Sometimes smart people can be so damn dumb...

Bitcoin: The currency of liberty
1HBJSf3Lm9i8KxjZ7fuoN9FJ8hniniFbv4
mmitech (OP)
Legendary
*
Offline Offline

Activity: 1148
Merit: 1001


things you own end up owning you


View Profile
February 10, 2014, 10:33:32 PM
 #11

ok got it, but supposedly we will fix the Malleability issue today, how will this fix all their issues ?

It won't and it won't be "fixed".  It is a limitation of the system that we have to deal with.  The reference client does a good job of handling it.  Those who can't do a better job shouldn't attempt to do so.  Even if it was going to be "fixed" by a hard fork that would be months if not years.  From proposal to final release P2SH took 10+ months.  This would be a much more radical change to the core protocol.  IMHO it will NEVER happen but if it did, do you honestly think MtGox just holding on to the coins for 10 months is a viable solution?  With a small amount of competence malleability can be detected.

Quote
they will still have ton of other issues on their side, this is what I really don't get, do they take us for idiots ?

I don't what they take "us" for but yes this wouldn't affect the half dozen other critical flaws in the client.  It also won't "undo" the unknown number of bitcoins they double paid to attackers.

I will add this, I missed replying to from your first reply

Quote
Your right if you send out payments to 50,000 users and 49,999 report no issue but one user over and over reports not getting paid well then "hmm maybe this user is running a scam" however if you send payments to 50,000 users and 30,000 of them report non-payment due to a variety of reasons (caused by Gox) then it becomes easier for the attacker to hide.

we are still talking about one "failed transaction", you can miss on 1,2,5 or 10 users but you still have the other 900 that got their Bitcoins even if their tx says different, users wouldn't complain, it is even a good transaction and all users get their BTC regardless the tx or no one get anything...
bitcoinminer
Sr. Member
****
Offline Offline

Activity: 322
Merit: 252



View Profile
February 10, 2014, 10:35:18 PM
 #12

Someone explain something to me. Why would the attackers do this knowing that they would cause the price to tank? If it causes BTC to be worthless then they're also SOL. Maybe they didn't think they would get caught somehow? Sometimes smart people can be so damn dumb...

If you stole $100,000 knowing you could sell it for $50,000, you're nothing thinking "Awww jeez, if I hadn't stole the $100,000 I wouldn't have driven the price down!"

They're not taking a $50,000 loss on $100,000, they're taking a $50,000 gain on ZERO.

Be fearful when others are greedy, and greedy when others are fearful.

-Warren Buffett
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1079


Gerald Davis


View Profile
February 10, 2014, 10:46:39 PM
 #13

Someone explain something to me. Why would the attackers do this knowing that they would cause the price to tank? If it causes BTC to be worthless then they're also SOL. Maybe they didn't think they would get caught somehow? Sometimes smart people can be so damn dumb...

Worthless would imply that the value went to zero which it hasn't.

Say you had 100 BTC at MTGox and you withdrew, modified, reported not getting paid, and got paid again.  You now have 200 BTC.  Your break even if if you can sell those 200 BTC at half the price you could have sold the 100 BTC at.  But wait this has been going on for a month now.  So say you deposit the 200 BTC back to your MtGox account ,withdraw it, modify it, report it not being paid, get paid again and now you have 400 BTC.  The price would have to fall 75% before you sold it to take a loss.   Now 400 BTC to 800 BTC the price would have to fall 87% for you to not profit.

It is also possible the attacker(s) sold their "doubled" coins weeks ago long before the price ever tanked.  Hell they might have even sold, waited for the price to tank, and then bought back near the lows to make even more profit on their double.
vpitcher07
Sr. Member
****
Offline Offline

Activity: 342
Merit: 250


View Profile
February 10, 2014, 11:47:04 PM
 #14

Someone explain something to me. Why would the attackers do this knowing that they would cause the price to tank? If it causes BTC to be worthless then they're also SOL. Maybe they didn't think they would get caught somehow? Sometimes smart people can be so damn dumb...

Worthless would imply that the value went to zero which it hasn't.

Say you had 100 BTC at MTGox and you withdrew, modified, reported not getting paid, and got paid again.  You now have 200 BTC.  Your break even if if you can sell those 200 BTC at half the price you could have sold the 100 BTC at.  But wait this has been going on for a month now.  So say you deposit the 200 BTC back to your MtGox account ,withdraw it, modify it, report it not being paid, get paid again and now you have 400 BTC.  The price would have to fall 75% before you sold it to take a loss.   Now 400 BTC to 800 BTC the price would have to fall 87% for you to not profit.

It is also possible the attacker(s) sold their "doubled" coins weeks ago long before the price ever tanked.  Hell they might have even sold, waited for the price to tank, and then bought back near the lows to make even more profit on their double.

Very true, I just don't sometimes see the logic of doing things that can potentially ruin the system in which you are exploiting for profit.

Bitcoin: The currency of liberty
1HBJSf3Lm9i8KxjZ7fuoN9FJ8hniniFbv4
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1079


Gerald Davis


View Profile
February 10, 2014, 11:51:15 PM
 #15

It won't ruin the system.  If this could kill Bitcoin, then Bitcoin was never worth anything to begin with.  It might cause a short term drop in the exchange rate and even still the attacker still comes out ahead.

Some people will kill you for the cash in your wallet, and you don't think a hacker would exploit a door MtGox left wide open, to instantly double or quadruple (or more) their wealth with little to no risk, just because it might cause a short term drop in the exchange rate?  Really?
TitanBTC
Sr. Member
****
Offline Offline

Activity: 366
Merit: 258



View Profile WWW
February 11, 2014, 12:09:22 AM
 #16

It won't ruin the system.  If this could kill Bitcoin, then Bitcoin was never worth anything to begin with. 

Well said.


 

vpitcher07
Sr. Member
****
Offline Offline

Activity: 342
Merit: 250


View Profile
February 11, 2014, 12:20:45 AM
 #17

It won't ruin the system.  If this could kill Bitcoin, then Bitcoin was never worth anything to begin with.  It might cause a short term drop in the exchange rate and even still the attacker still comes out ahead.

Some people will kill you for the cash in your wallet, and you don't think a hacker would exploit a door MtGox left wide open, to instantly double or quadruple (or more) their wealth with little to no risk, just because it might cause a short term drop in the exchange rate?  Really?

No I meant in general, not just bitcoin. I did not mean to make it sound like I thought this was going to ruin bitcoin.

Bitcoin: The currency of liberty
1HBJSf3Lm9i8KxjZ7fuoN9FJ8hniniFbv4
darkphantom934
Full Member
***
Offline Offline

Activity: 141
Merit: 100


View Profile
February 11, 2014, 02:26:43 AM
 #18

Close.

1.) People send BTC to GOXXX
2.) GOXXX Takes the BTC
3.) Nobody can withdraw

I loled
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!