Bitcoin Forum
September 27, 2018, 11:01:33 PM *
News: ♦♦ New info! Bitcoin Core users absolutely must upgrade to previously-announced 0.16.3 [Torrent]. All Bitcoin users should temporarily trust confirmations slightly less. More info.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Timing of exploitation of bug  (Read 628 times)
Kaiji
Full Member
***
Offline Offline

Activity: 140
Merit: 100


Hoist the Colours


View Profile
February 16, 2014, 07:49:29 PM
 #1


How come this bug in the bitcoin protocol wasn't exploited before? I am sure every hackercriminal in the world was trying to rob from the system. The timing seems a little fishy to me?
1538089293
Hero Member
*
Offline Offline

Posts: 1538089293

View Profile Personal Message (Offline)

Ignore
1538089293
Reply with quote  #2

1538089293
Report to moderator
1538089293
Hero Member
*
Offline Offline

Posts: 1538089293

View Profile Personal Message (Offline)

Ignore
1538089293
Reply with quote  #2

1538089293
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1538089293
Hero Member
*
Offline Offline

Posts: 1538089293

View Profile Personal Message (Offline)

Ignore
1538089293
Reply with quote  #2

1538089293
Report to moderator
1538089293
Hero Member
*
Offline Offline

Posts: 1538089293

View Profile Personal Message (Offline)

Ignore
1538089293
Reply with quote  #2

1538089293
Report to moderator
1538089293
Hero Member
*
Offline Offline

Posts: 1538089293

View Profile Personal Message (Offline)

Ignore
1538089293
Reply with quote  #2

1538089293
Report to moderator
Foxpup
Legendary
*
Offline Offline

Activity: 2324
Merit: 1148



View Profile
February 16, 2014, 09:13:30 PM
 #2

It wasn't exploited before because it's not actually exploitable at all. Exploiting it requires a human to believe that unconfirmed transactions are immutable, and nobody's that stupid, right? Right?

Will pretend to do unverifiable things (while actually eating an enchilada-style burrito) for bitcoins: 1K6d1EviQKX3SVKjPYmJGyWBb1avbmCFM4
Remember remember the 5th of November
Legendary
*
Offline Offline

Activity: 1750
Merit: 1001

Reverse engineer from time to time


View Profile
February 16, 2014, 09:20:46 PM
 #3

It wasn't exploited before because it's not actually exploitable at all. Exploiting it requires a human to believe that unconfirmed transactions are immutable, and nobody's that stupid, right? Right?
Yay, let's all start writing in riddles. The OP's question is interesting, because indeed why not before and why recently.

BTC:1AiCRMxgf1ptVQwx6hDuKMu4f7F27QmJC2
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1005


Gerald Davis


View Profile
February 16, 2014, 09:24:37 PM
 #4

MtGox left the door "open" when their nodes started writing garbage non-compliant transactions.  Prior to v0.8 most of MtGox garbage tx were still relayed by other nodes.  With prompt relaying it becomes very difficulty to modify the tx and then win a race.  As the number of v0.8+ nodes started increasing, transactions created by MtGox started having a harder and harder time propogating the network.

Like a critical cascading failure this flaw exposed other flaws in MtGox "GOX SPECIAL v0" client they hacked together without basic knowledge of the protocol.  Their client would attempt to create tx without sufficient tx fees (despite charging users 10x the min mandatory fee). Their client would attempt to spend immature newly mined coins.  Rather than fix issues they simply modified the client to spend older and larger "coins" first.

This really came to a critical level in the last 30 days when the percentage of legit withdraws became massive.  By now most of the network was v0.8+ so they were just dropping MtGox tx, the need to continually recreate withdraws over and over not only provided the attacker with "cover", it also exhausted their pool of old, large coins, exposing the the other issues with insufficient fees and spending immature coins. The flaws in their design compounded upon each other to create this massive (at one point >2,800 tx and anecdotally more than 50% failure rate) backlog of broken withdraws.

My guess is someone figured out they could take the garbage tx non-compliant tx, clean it up and get paid faster.  From there it was only a small leap in logic to "wait a second, MtGox servers still show the old tx hash.  I bet I could tell them I haven't been paid and blend right in with the thousands upon thousands of legit reports of broken transactions". 

Of course if the ONLY problems MTGox had were non-canonical signature, spending immature coins, double spending their own payments (race condition?), and paying insufficient fees the attacker STILL couldn't have stolen funds.  Like I said this just opened the door.  That combined with relying on tx ids and resending payments without investigation after a report on non-payment is what made the attack profitable.
cr1776
Legendary
*
Offline Offline

Activity: 2016
Merit: 1007


View Profile
February 16, 2014, 09:26:59 PM
 #5

Few realized that mtgox (and, perhaps SR2 if they are being truthful) was only verifying based on tx id and nothing else.  So it was only recently that someone realized that people had bugs in their code or process, as foxpup said, and then exploited these bugs.

hjbuell
Member
**
Offline Offline

Activity: 70
Merit: 10

Writer $0.10/word +


View Profile WWW
February 16, 2014, 09:35:44 PM
 #6

Death and Taxes is the official winner of this thread Cheesy

Being different is all it takes to make a difference. H. J. Buell
Writer from $0.10 per word. https://hjbuell.com
bitpop
Legendary
*
Offline Offline

Activity: 2366
Merit: 1043


https://keybase.io/bitpop


View Profile WWW
February 17, 2014, 02:21:29 PM
 #7

.

Reputation  |  PGP  |  DigitalOcean  |  TorGuard  |  Ethereum Classic
Bitcoin: 3DSh6AnmvBpDJFUz2mnLirMLmTMcFs9nDm
Bitmessage: BM-2cXN9j8NFT2n1FxDVQ6HQq4D4MZuuaBFyb
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!